戰(zhàn)：虛擬串口對+Python實(shí)現(xiàn)協(xié)議自動(dòng)化測試)
1. 從“板子還在路上”說起串口模擬工具到底解決什么問題手上只有一份協(xié)議文檔硬件板子還在物流途中上位機(jī)代碼卻要趕在明天上午聯(lián)調(diào)完——這種場面我經(jīng)歷過不止一次。串口模擬工具就是給這種場景準(zhǔn)備的救火隊(duì)員它不產(chǎn)生真實(shí)的 TTL 電平也不占用你機(jī)箱上的物理 USB 口而是在操作系統(tǒng)層面虛擬出一對或多對串口讓上位機(jī)軟件以為自己插上了一根 USB 轉(zhuǎn) TTL 線實(shí)際上線的另一端坐著一個(gè)能按協(xié)議回?cái)?shù)據(jù)的程序。串口測試?yán)镒詈臅r(shí)間的從來不是收發(fā)動(dòng)作本身而是“等硬件”“復(fù)現(xiàn)偶發(fā)異?！薄膀?yàn)證邊界幀”這三件事而模擬工具恰好能把這三點(diǎn)都扳回來。先說清楚它不是什么。模擬工具替代不了電磁兼容測試、替代不了真實(shí)的 RS485 總線負(fù)載、替代不了串口燒寫過程中那頭具體的 MCU。但它能把 80% 的協(xié)議邏輯驗(yàn)證、幀格式校驗(yàn)、異常分支覆蓋放在硬件到貨之前完成剩下 20% 的硬件相關(guān)特性再上真板子收尾。這個(gè)分工一旦劃清楚整個(gè)項(xiàng)目的節(jié)奏會順很多也不會出現(xiàn)“板子一到手全都在改低級 bug”的尷尬。這篇文章寫給三類人正在做上位機(jī)串口開發(fā)但缺硬件的工程師、需要用自動(dòng)化測試批量回歸串口協(xié)議的測試同學(xué)、以及被CH340 驅(qū)動(dòng)和波特率對不上折磨過的新手。我會從底層通信機(jī)制講到虛擬串口對的建立再給出一套可以直接抄作業(yè)的 Python 模擬工具實(shí)現(xiàn)最后把踩過的坑整理成速查表。文中沒有模棱兩可的“建議考慮”所有參數(shù)和代碼都在我自己的機(jī)器上跑過。1.1 真實(shí)串口調(diào)試最讓人頭疼的三個(gè)卡點(diǎn)第一個(gè)卡點(diǎn)是硬件不在位。嵌入式項(xiàng)目里上位機(jī)和下位機(jī)經(jīng)常是兩個(gè)團(tuán)隊(duì)并行推進(jìn)下位機(jī)固件還在調(diào)傳感器上位機(jī)的通信模塊只能干等。等板子到了兩邊的 bug 混在一起到底是協(xié)議解析寫錯(cuò)了還是對方發(fā)送時(shí)序有偏差排查起來互相甩鍋。第二個(gè)卡點(diǎn)是偶發(fā)異常難復(fù)現(xiàn)。比如某條命令在連續(xù)發(fā)送 10 萬次后偶發(fā)回復(fù)錯(cuò)幀真實(shí)硬件上你要掛機(jī)跑一整天才能撞上一次。模擬工具可以直接構(gòu)造“第 99999 幀故意延遲 200ms 回復(fù)”這種劇本幾秒鐘就能復(fù)現(xiàn)定位效率完全不是一個(gè)量級。第三個(gè)卡點(diǎn)是邊界用例成本高。超長幀、校驗(yàn)錯(cuò)、幀頭粘連、半包數(shù)據(jù)、粘包數(shù)據(jù)這些異常幀用真硬件注入非常別扭要么改固件專門加測試分支要么用信號發(fā)生器硬湊。虛擬串口這一側(cè)寫代碼隨意構(gòu)造字節(jié)流想發(fā)什么發(fā)什么測完刪掉即可不留任何副作用。注意模擬工具驗(yàn)證的是“協(xié)議邏輯與上位機(jī)魯棒性”它無法證明你的硬件電路在強(qiáng)干擾下不掉線也無法驗(yàn)證 RS485 收發(fā)切換的時(shí)序余量。這兩塊必須留給真板子。1.2 模擬工具的能力邊界先劃清楚再動(dòng)手我見過有人指望模擬工具能測出電源紋波導(dǎo)致的串口通信誤碼這是方向錯(cuò)了。模擬工具體驗(yàn)的是純軟件鏈路從應(yīng)用程序緩沖區(qū)到虛擬驅(qū)動(dòng)緩沖區(qū)中間沒有任何模擬信號。它的價(jià)值集中在數(shù)據(jù)鏈路層以上的邏輯幀結(jié)構(gòu)、命令字、長度域、校驗(yàn)算法、超時(shí)重傳、多幀拼接、狀態(tài)機(jī)跳轉(zhuǎn)。反過來說凡是和電氣特性、uart 串口通信電平、共模干擾、地環(huán)路相關(guān)的測試模擬工具一律不碰。把邊界寫進(jìn)測試計(jì)劃的“適用范圍”一欄后面評審時(shí)不會有人拿這個(gè)來質(zhì)疑測試充分性。我自己的習(xí)慣是在測試報(bào)告開頭明確寫一行本次驗(yàn)證覆蓋協(xié)議層物理層特性另行安排。還有一個(gè)容易忽略的邊界USB 轉(zhuǎn)串口芯片帶來的驅(qū)動(dòng)層行為。CH340、CP2102、FT232 這些芯片在驅(qū)動(dòng)層面有各自的緩沖區(qū)大小和超時(shí)特性虛擬串口對是沒有這些特性的。所以在模擬環(huán)境里跑通的超時(shí)參數(shù)搬到真板子上可能要重新標(biāo)定一次這一點(diǎn)后面第 6 節(jié)會詳細(xì)講。2. 串口通信的底層邏輯與模擬工具的介入點(diǎn)要明白模擬工具為什么能騙過上位機(jī)得先知道一個(gè)字節(jié)是怎么從代碼走到線上的。應(yīng)用程序調(diào)用 write 把一串字節(jié)交給內(nèi)核串口驅(qū)動(dòng)驅(qū)動(dòng)把它推到 UART 控制器的發(fā)送 FIFO硬件再按波特率一位一位地把電平翻轉(zhuǎn)出去。接收方向反過來起始位觸發(fā)采樣移位寄存器攢滿 8 位就產(chǎn)生接收中斷驅(qū)動(dòng)讀走數(shù)據(jù)放進(jìn)緩沖區(qū)應(yīng)用程序再 read 出來。波特率決定了每一位的時(shí)間寬度。115200bps 意味著每位約 8.68 微秒一個(gè)標(biāo)準(zhǔn) 10 位幀1 起始 8 數(shù)據(jù) 1 停止大約 86.8 微秒。這個(gè)數(shù)字在模擬環(huán)境里沒有物理意義但它決定了上位機(jī)的超時(shí)閾值該怎么算——比如等待一個(gè) 20 字節(jié)的回復(fù)理論傳輸時(shí)間約 1.74 毫秒考慮到調(diào)度抖動(dòng)超時(shí)設(shè) 50 到 100 毫秒比較從容。2.1 一條數(shù)據(jù)從應(yīng)用程序到虛擬串口對的路徑在 Linux 下虛擬串口對由偽終端pty實(shí)現(xiàn)。socat 創(chuàng)建兩個(gè)配對的 pty 設(shè)備節(jié)點(diǎn)比如 /dev/pts/3 和 /dev/pts/4寫進(jìn)其中一個(gè)的數(shù)據(jù)會從另一個(gè)讀出來行為上和一根交叉連接的串口線完全一致。上位機(jī)打開 /dev/pts/3模擬程序打開 /dev/pts/4雙方都以為自己在和真實(shí)硬件說話。Windows 下沒有 pty 這套機(jī)制靠的是虛擬串口驅(qū)動(dòng)比如開源的 com0com 或者商用軟件里的對應(yīng)功能。它注冊一對 COM 口例如 COM10 和 COM11驅(qū)動(dòng)層直接把寫入 COM10 的數(shù)據(jù)轉(zhuǎn)發(fā)到 COM11 的接收緩沖。上位機(jī)打開 COM10模擬程序打開 COM11鏈路就通了。要注意這兩個(gè)端口號必須是成對創(chuàng)建的單獨(dú)一個(gè)虛擬 COM 口沒有任何對端打開后會一直 read 超時(shí)。Mac 下依然走 pty 那套socat 或者自帶的 screen 配合 pty 都能用路徑形如 /dev/ttys00x。三套系統(tǒng)的實(shí)現(xiàn)機(jī)制不同但對上位機(jī)而言都是“一個(gè)普通串口”這就是模擬方案通用性的根源——不對上層暴露任何差異。2.2 模擬工具到底站在協(xié)議棧的哪一層模擬工具站在“字符設(shè)備之上、應(yīng)用協(xié)議之下”。它不做電氣層的比特翻轉(zhuǎn)但要完整承擔(dān)字節(jié)流的組織與解析。這意味著兩件事必須由我們自己負(fù)責(zé)一是分幀二是應(yīng)答時(shí)序。分幀是把連續(xù)字節(jié)流按協(xié)議切成一條條完整報(bào)文應(yīng)答時(shí)序是決定收到命令后立即回復(fù)還是延遲回復(fù)、分幾次回復(fù)、故意錯(cuò)發(fā)一次再補(bǔ)發(fā)正確幀。我傾向把這層邏輯寫成一個(gè)獨(dú)立的“協(xié)議引擎”模塊和串口收發(fā)模塊解耦。串口收發(fā)模塊只負(fù)責(zé) open、read、write、close協(xié)議引擎只負(fù)責(zé)字節(jié)數(shù)組進(jìn)、字節(jié)數(shù)組出。好處是這套引擎既能在虛擬串口上跑也能在真串口上跑將來還能接到網(wǎng)絡(luò) Socket 或者 MQTT 上做虛擬串口軟件式的轉(zhuǎn)發(fā)復(fù)用率極高。這個(gè)分層是在被兩三個(gè)項(xiàng)目折磨之后才定下來的一開始全塞在一個(gè)腳本里改起來非常痛苦。3. 方案選型虛擬串口對、腳本模擬、硬件仿真三種路線怎么選市面上的方案大致分三類沒有絕對優(yōu)劣取決于你要驗(yàn)證什么、團(tuán)隊(duì)在什么系統(tǒng)上開發(fā)。選錯(cuò)路線最典型的后果是時(shí)間花在折騰工具本身而不是驗(yàn)證業(yè)務(wù)協(xié)議。第一類是虛擬串口對 自研模擬程序。底層用 socat 或 com0com 建立成對端口上層自己寫 Python 或 C# 程序?qū)崿F(xiàn)協(xié)議應(yīng)答。靈活度最高能精確控制每一幀的時(shí)序和內(nèi)容異常注入想怎么玩怎么玩。代價(jià)是要自己寫代碼前期投入大概一天。第二類是現(xiàn)成的串口調(diào)試助手。XCOM、SSCOM、友善串口助手這類工具都支持定時(shí)發(fā)送、十六進(jìn)制收發(fā)、多條指令輪發(fā)。它們適合手動(dòng)驗(yàn)證單條命令但要做“收到 A 命令后按條件回復(fù) B 幀”這種交互邏輯就很吃力基本只能靠人工點(diǎn)發(fā)送。做回歸測試時(shí)不推薦效率太低。第三類是帶腳本的增強(qiáng)型模擬軟件可以理解為調(diào)試助手加了一個(gè)規(guī)則引擎收到指定幀自動(dòng)觸發(fā)回復(fù)。上手快不用寫代碼但復(fù)雜協(xié)議比如帶變長負(fù)載和 CRC 校驗(yàn)的配置起來反而繞。適合協(xié)議簡單、用例不多的場景。3.1 三種路線的橫向?qū)Ρ葘Ρ染S度虛擬串口對 自研程序串口調(diào)試助手手動(dòng)帶腳本的增強(qiáng)模擬軟件協(xié)議復(fù)雜度承載能力高任意邏輯低僅手動(dòng)中受規(guī)則引擎限制異常幀注入完全可控手動(dòng)拼十六進(jìn)制部分支持自動(dòng)化回歸天然支持不支持有限支持前期投入約 1 人天幾乎為零約 2 小時(shí)長期維護(hù)成本低代碼即文檔高全靠人工中適合場景協(xié)議測試、持續(xù)集成臨時(shí)抓包、單條驗(yàn)證快速原型、輕量驗(yàn)證從表里能看出如果項(xiàng)目周期超過兩周且需要回歸虛擬串口對加自研程序幾乎是唯一劃算的選擇。前期多花的那一天會在后續(xù)每次改協(xié)議、每次回歸里加倍省回來。我做過一個(gè)小統(tǒng)計(jì)某項(xiàng)目用自研模擬工具后通信模塊的單輪回歸時(shí)間從人工 40 分鐘壓到腳本 90 秒改了 11 輪協(xié)議就省出了整整一天。3.2 選型時(shí)最容易忽略的兩個(gè)隱藏成本第一個(gè)隱藏成本是跨平臺。如果團(tuán)隊(duì)里有人用 Windows、有人用 Linux虛擬串口對的建立方式完全不同模擬程序的串口路徑要參數(shù)化不能寫死 /dev/pts/3。我通常把端口名做成配置文件項(xiàng)或命令行參數(shù)甚至用環(huán)境變量注入避免換臺機(jī)器就報(bào)“找不到串口”。第二個(gè)隱藏成本是端口號漂移。Linux 下 pty 的編號是動(dòng)態(tài)分配的這次是 /dev/pts/3下次可能是 /dev/pts/7。解決辦法是 socat 輸出創(chuàng)建結(jié)果后程序解析或者干脆用固定的符號鏈接指向它。Windows 下 com0com 分配的是固定 COM 號相對省心但偶爾會被系統(tǒng)占用沖突。這些小事不提前想第一次跑就會卡住。提示把“建立虛擬串口對”這一步單獨(dú)寫成一個(gè)啟動(dòng)腳本成功后再拉起模擬程序中間加一個(gè)端口就緒的探測循環(huán)。否則容易出現(xiàn)上位機(jī)先打開、pty 還沒創(chuàng)建完的競態(tài)。4. 手把手搭建用 Python 寫一個(gè)可配置的串口模擬工具下面這套實(shí)現(xiàn)是我目前項(xiàng)目里在用的簡化版去掉業(yè)務(wù)相關(guān)代碼后大約兩百行跑在 Python 3.8 以上依賴只有 pyserial。它的設(shè)計(jì)目標(biāo)是一套協(xié)議引擎能掛在虛擬串口上也能掛在真串口上支持變長幀、CRC16 校驗(yàn)、按命令字分派處理函數(shù)、可控的應(yīng)答延遲和錯(cuò)誤注入。先明確協(xié)議幀格式這個(gè)格式是我按常見工業(yè)協(xié)議抽象出來的你可以按自己的實(shí)際協(xié)議替換字段含義------------------------------------------------- | 幀頭 | 長度 | 命令字 | 數(shù)據(jù)區(qū) | CRC16 | 幀尾 | | 2 字節(jié) | 1 字節(jié) | 1 字節(jié) | N 字節(jié) | 2 字節(jié) | 1 字節(jié) | | AA 55 | len | cmd | ... | 低字節(jié)在前 | 0D | -------------------------------------------------長度域統(tǒng)計(jì)的是從命令字到數(shù)據(jù)區(qū)結(jié)束的字節(jié)數(shù)CRC 計(jì)算范圍是長度域、命令字、數(shù)據(jù)區(qū)不包含幀頭幀尾。這套定義在解析時(shí)要嚴(yán)格遵守否則半包拼接永遠(yuǎn)對不上。4.1 環(huán)境準(zhǔn)備與依賴安裝Linux 下不需要額外安裝虛擬串口驅(qū)動(dòng)裝 socat 即可# Debian/Ubuntu 系 sudo apt-get install socat # 驗(yàn)證版本 socat -VWindows 下推薦用開源的 com0com安裝后打開它的 Setup 圖形界面添加一對端口例如 COM10 和 COM11勾選“use Ports class”可以偽裝成標(biāo)準(zhǔn)串口設(shè)備。裝完后在設(shè)備管理器里應(yīng)該能看到這對端口。如果設(shè)備的串口燒寫失敗、提示找不到端口八成是驅(qū)動(dòng)沒簽名或者被系統(tǒng)攔了這類CH340 串口驅(qū)動(dòng)相關(guān)的問題在 Windows 上很常見后面第 6 節(jié)會專門說。Python 側(cè)只需要一個(gè)庫pip install pyserial驗(yàn)證 pyserial 能否枚舉端口python -m serial.tools.list_ports這一步能列出你建好的虛擬端口就說明驅(qū)動(dòng) OK。4.2 建立虛擬串口對并確認(rèn)鏈路Linux/Mac 下用一條命令建立成對 pty并把兩個(gè)端口名打印出來socat -d -d pty,raw,echo0,link/tmp/ttyV0 pty,raw,echo0,link/tmp/ttyV1執(zhí)行后會停在終端不返回這是正常的它作為守護(hù)進(jìn)程持續(xù)轉(zhuǎn)發(fā)數(shù)據(jù)。另開一個(gè)終端檢查ls -l /tmp/ttyV0 /tmp/ttyV1兩個(gè)符號鏈接會指向?qū)嶋H的 /dev/pts/N。這種用固定符號鏈接的做法解決了前面說的端口號漂移問題程序里直接填 /tmp/ttyV0 即可。參數(shù)里 raw 表示不做任何字符轉(zhuǎn)換echo0 表示不回顯這兩個(gè)必須加否則你會看到一個(gè)端口發(fā)出去的數(shù)據(jù)從自己這里讀回來誤以為是協(xié)議 bug。Windows 下端口就是 COM10 和 COM11無需命令模擬程序開 COM11上位機(jī)開 COM10。4.3 核心代碼幀解析與命令分派先寫 CRC16-MODBUS這個(gè)算法在工業(yè)設(shè)備里出現(xiàn)頻率極高低字節(jié)在前發(fā)送def crc16_modbus(data: bytes) - int: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc再寫一個(gè)帶環(huán)形緩沖的解析器這是整個(gè)工具里最容易寫錯(cuò)的部分。很多人一上來就對 read 到的整塊數(shù)據(jù)切幀遇到半包立刻崩。正確做法是維護(hù)一個(gè) bytearray每次把新數(shù)據(jù)追加進(jìn)去然后循環(huán)嘗試切出一條完整幀切不出來就等著class FrameParser: HEAD b\xAA\x55 TAIL b\x0D def __init__(self): self.buf bytearray() def feed(self, chunk: bytes): self.buf.extend(chunk) frames [] while True: frame self._try_extract() if frame is None: break frames.append(frame) return frames def _try_extract(self): # 找?guī)^ idx self.buf.find(self.HEAD) if idx 0: # 沒有幀頭只保留最后一個(gè)字節(jié)防跨包 if len(self.buf) 1: del self.buf[:-1] return None if idx 0: del self.buf[:idx] # 丟棄幀頭前的垃圾數(shù)據(jù) # 幀頭 長度域至少 3 字節(jié) if len(self.buf) 3: return None length self.buf[2] total 2 1 length 2 1 # 頭 長 體 CRC 尾 if len(self.buf) total: return None candidate bytes(self.buf[:total]) if candidate[-1] ! self.TAIL[0]: del self.buf[:2] return None calc crc16_modbus(candidate[2:3 length]) recv candidate[3 length] | (candidate[4 length] 8) if calc ! recv: del self.buf[:2] return None del self.buf[:total] return candidate這里有個(gè)細(xì)節(jié)值得強(qiáng)調(diào)校驗(yàn)失敗時(shí)我只丟棄兩個(gè)字節(jié)的幀頭而不是整幀丟掉。原因是數(shù)據(jù)流里可能出現(xiàn)“假幀頭”如果按偽長度直接跳過一整幀真實(shí)的幀頭可能就被誤吞了。逐字節(jié)滑動(dòng)重新找?guī)^魯棒性最好。當(dāng)然這會帶來一點(diǎn)點(diǎn)重解析開銷但對串口這種低速鏈路完全無所謂。接下來是模擬從機(jī)的收發(fā)主循環(huán)命令字分派用字典import serial import time class MockSlave: def __init__(self, port, baudrate115200, delay0.01, inject_errorFalse): self.ser serial.Serial( portport, baudratebaudrate, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout0.02, ) self.parser FrameParser() self.delay delay self.inject_error inject_error self.counter 0 self.handlers { 0x01: self.handle_read_status, 0x02: self.handle_write_param, 0x03: self.handle_heartbeat, } def build_frame(self, cmd: int, payload: bytes) - bytes: body bytes([len(payload) 1, cmd]) payload crc crc16_modbus(body) return b\xAA\x55 body bytes([crc 0xFF, crc 8]) b\x0D def handle_read_status(self, payload: bytes) - bytes: return bytes([0x00, 0x64, 0x01]) # 狀態(tài)正常, 溫度, 通道 def handle_write_param(self, payload: bytes) - bytes: return bytes([0x00]) def handle_heartbeat(self, payload: bytes) - bytes: self.counter 1 return bytes([0x00, self.counter 0xFF]) def run_forever(self): while True: chunk self.ser.read(256) if not chunk: continue for frame in self.parser.feed(chunk): cmd frame[3] length frame[2] payload frame[4:3 length] handler self.handlers.get(cmd) if handler is None: resp_payload bytes([0x01]) # 不支持的命令 else: resp_payload handler(payload) time.sleep(self.delay) if self.inject_error and self.counter % 7 0: resp self.build_frame(cmd, resp_payload)[:-4] # 故意截?cái)?else: resp self.build_frame(cmd, resp_payload) self.ser.write(resp) if __name__ __main__: slave MockSlave(/tmp/ttyV1, baudrate115200, delay0.005) slave.run_forever()這段代碼里幾個(gè)參數(shù)都是可調(diào)的delay 控制應(yīng)答延遲用來測上位機(jī)的超時(shí)邏輯inject_error 打開后每 7 幀故意發(fā)一條殘缺幀驗(yàn)證上位機(jī)對錯(cuò)幀的處理。實(shí)測把 delay 調(diào)到 0.2 秒時(shí)我那份超時(shí)閾值設(shè) 100 毫秒的上位機(jī)立刻報(bào)超時(shí)并重發(fā)說明超時(shí)機(jī)制工作正常。4.4 配一個(gè)自動(dòng)化回歸腳本收尾模擬從機(jī)跑起來后上位機(jī)的驗(yàn)證就可以完全自動(dòng)化。下面這段腳本模擬上位機(jī)行為逐條發(fā)命令、斷言回復(fù)import serial import time import pytest PORT_MASTER /tmp/ttyV0 def build(cmd, payloadb): body bytes([len(payload) 1, cmd]) payload crc crc16_modbus(body) return b\xAA\x55 body bytes([crc 0xFF, crc 8]) b\x0D pytest.fixture def master(): ser serial.Serial(PORT_MASTER, 115200, timeout0.1) yield ser ser.close() def read_one(ser): parser FrameParser() deadline time.time() 1.0 while time.time() deadline: frames parser.feed(ser.read(256)) if frames: return frames[0] return None def test_read_status(master): master.write(build(0x01)) resp read_one(master) assert resp is not None assert resp[3] 0x01 assert resp[4] 0x00 def test_heartbeat_increments(master): seen set() for _ in range(5): master.write(build(0x03)) resp read_one(master) assert resp is not None seen.add(resp[4]) assert len(seen) 5 # 每個(gè)心跳計(jì)數(shù)應(yīng)不同用 pytest 跑起來就是一條命令的事配合持續(xù)集成可以做到每次提交自動(dòng)回歸。這套東西搭好之后協(xié)議改動(dòng)的驗(yàn)證成本幾乎降到零。5. 測試結(jié)論怎么來的功能、邊界、壓力三類用例設(shè)計(jì)工具能跑通只是第一步真正決定測試結(jié)論可信度的是用例設(shè)計(jì)。我習(xí)慣把串口類用例拆成三層功能層保證主流程對邊界層保證異常輸入不崩壓力層保證長時(shí)間運(yùn)行不泄漏不卡死。三層都過了才敢在報(bào)告里寫“通過”。5.1 功能用例把每條命令的正常路徑走一遍功能層最直接針對協(xié)議文檔里每一條命令字構(gòu)造合法請求斷言響應(yīng)字段含義正確。這里有兩個(gè)細(xì)節(jié)值得展開。一是響應(yīng)內(nèi)容要覆蓋所有分支。比如讀狀態(tài)命令正常返回 0x00但設(shè)備可能處于告警、離線、初始化中等狀態(tài)模擬工具應(yīng)該能按參數(shù)切換返回不同狀態(tài)碼讓上位機(jī)的狀態(tài)機(jī)每個(gè)分支都被執(zhí)行到。如果模擬工具只會返回一種狀態(tài)上位機(jī)的告警處理邏輯永遠(yuǎn)是沒測過的死代碼。二是請求參數(shù)要有代表性組合。寫參數(shù)命令往往有多個(gè)字段全用 0 和全用最大值是最沒營養(yǎng)的測法。我的做法是選邊界值加隨機(jī)值混合字段 A 取最小值、字段 B 取最大值、字段 C 取隨機(jī)中間值跑幾十組。隨機(jī)數(shù)種子固定保證失敗可復(fù)現(xiàn)。這塊我在一個(gè)項(xiàng)目里吃過教訓(xùn)寫參數(shù)命令的校驗(yàn)邏輯只測了合法值上線后遇到設(shè)備端傳回全 0xFF 的非法參數(shù)直接解析越界。補(bǔ)上邊界用例只花了半小時(shí)省下的現(xiàn)場排查時(shí)間按天算。5.2 邊界與異常用例丑幀才是真考驗(yàn)邊界層是模擬工具真正的主場。下面這些幀類型建議全部覆蓋異常類型構(gòu)造方法期望上位機(jī)行為半包幀先發(fā)前半截延遲 50ms 再發(fā)后半截正確拼接不誤判為錯(cuò)幀粘包幀兩條完整幀一次性連續(xù)發(fā)送完整切分成兩條都正確處理校驗(yàn)錯(cuò)故意把 CRC 改錯(cuò)丟棄該幀不回應(yīng)答不崩潰長度域超限length 填一個(gè)遠(yuǎn)超實(shí)際的巨大值等待超時(shí)后丟棄緩沖區(qū)不無限增長幀頭粘連幀頭后緊跟另一幀頭丟棄前段垃圾從第二個(gè)幀頭重新解析未知命令字cmd 填協(xié)議未定義值返回不支持錯(cuò)誤碼或按約定忽略非法幀尾幀尾字節(jié)被篡改判定為無效幀重新同步注意長度域超限這條最容易埋雷。如果解析器按 length 預(yù)分配緩沖區(qū)一個(gè)偽造的巨大 length 就能讓內(nèi)存爆掉。我的做法是給 length 設(shè)一個(gè)上限常量超過直接丟棄當(dāng)前候選幀并滑動(dòng)重新同步。異常用例還有一類是時(shí)序類比如兩幀間隔小于設(shè)備端處理周期、應(yīng)答延遲超過上位機(jī)超時(shí)閾值、上位機(jī)連發(fā)三幀不等回復(fù)。這些用模擬工具的 delay 參數(shù)就能構(gòu)造真硬件上反而難精確控制。5.3 壓力與長穩(wěn)跑夠時(shí)長再下結(jié)論壓力層關(guān)注三件事吞吐、內(nèi)存、穩(wěn)定性。吞吐上讓模擬工具以最高頻率收幀回幀持續(xù)跑一小時(shí)觀察上位機(jī)的處理隊(duì)列有沒有積壓、有沒有丟幀。串口本身速度有限115200bps 下理論上限也就每秒一千多幀短幀一般跑不滿瓶頸往往在上位機(jī)的解析線程。內(nèi)存上重點(diǎn)看解析緩沖區(qū)會不會隨錯(cuò)誤幀增長。如果每收到一條校驗(yàn)錯(cuò)幀就多留一段垃圾在 buffer 里跑一晚上內(nèi)存就上去了。驗(yàn)證方法很簡單讓模擬工具持續(xù)發(fā)錯(cuò)幀跑兩小時(shí)同時(shí)監(jiān)控上位機(jī)進(jìn)程的常駐內(nèi)存曲線應(yīng)該是平的。穩(wěn)定性上我一般設(shè)置一個(gè) 24 小時(shí)長穩(wěn)模擬工具按腳本隨機(jī)組合正常幀和異常幀上位機(jī)持續(xù)運(yùn)行不重啟。跑完之后檢查有無異常退出、有無句柄泄漏、日志里錯(cuò)誤率是否在預(yù)期范圍。這套組合拳跑下來測試結(jié)論才站得住腳。6. 踩坑記錄與常見問題速查這一節(jié)是我最想分享的部分因?yàn)橄旅孢@些問題幾乎每一個(gè)都讓我在現(xiàn)場多待了半小時(shí)以上。先說CH340 串口驅(qū)動(dòng)那點(diǎn)事。Windows 10 之后的系統(tǒng)對未簽名驅(qū)動(dòng)卡得很嚴(yán)有些老版本的 CH340 驅(qū)動(dòng)裝上后設(shè)備管理器能認(rèn)到端口但一打開就報(bào)“拒絕訪問”或者干脆收不到數(shù)據(jù)。遇到這種情況先卸載舊驅(qū)動(dòng)重啟再裝官網(wǎng)最新版。如果還是不行檢查設(shè)備管理器里該端口是否被標(biāo)記了黃色感嘆號有的話右鍵看錯(cuò)誤碼。另一個(gè)高頻坑是同一個(gè) CH340 芯片被兩套驅(qū)動(dòng)搶占表現(xiàn)為端口能打開但讀寫全是 0 字節(jié)設(shè)備管理器里能看到兩個(gè)條目刪掉多余的那個(gè)即可。再說串口接收數(shù)據(jù)丟失。Linux 下偶爾丟數(shù)據(jù)八成是讀取線程阻塞太久驅(qū)動(dòng)緩沖區(qū)溢出。解決無非兩條加大驅(qū)動(dòng)緩沖區(qū)stty 里的設(shè)置或者加快讀取頻率。我習(xí)慣開一個(gè)專職讀線程用最小 timeout 循環(huán) read讀到就塞進(jìn)隊(duì)列業(yè)務(wù)邏輯在另一個(gè)線程從隊(duì)列取寫日志這種耗時(shí)操作絕對不能在讀線程里做。這條經(jīng)驗(yàn)幫我解決了三次“偶發(fā)丟包”。還有串口關(guān)閉時(shí)的資源釋放。很多人寫程序只管 open 不管 close程序退出時(shí)端口沒釋放下次打開報(bào)“設(shè)備忙”。正確做法是把串口對象的關(guān)閉放進(jìn) finally 或者上下文管理器。如果還是遇到占用用 lsof 查一下哪個(gè)進(jìn)程還開著它Windows 下用資源監(jiān)視器搜句柄。6.1 高頻問題速查表現(xiàn)象可能原因排查與解決端口打不開提示被占用上個(gè)進(jìn)程未釋放lsof 查占用進(jìn)程殺進(jìn)程或重啟打開成功但收不到數(shù)據(jù)端口對端沒打開 / 端口配錯(cuò)對確認(rèn)虛擬串口對的另一端已連接收到自己發(fā)出的數(shù)據(jù)未關(guān)閉回顯pty 建鏈時(shí)加 echo0、raw數(shù)據(jù)偶爾丟失讀取線程阻塞緩沖溢出獨(dú)立讀線程最小超時(shí)循環(huán)讀亂碼波特率、校驗(yàn)位、停止位不一致逐項(xiàng)核對優(yōu)先懷疑波特率校驗(yàn)頻繁失敗分幀邏輯有誤或字節(jié)序搞反打印原始 hex核對 CRC 字節(jié)序虛擬端口下一臺機(jī)器找不到pty 編號漂移用符號鏈接固定路徑長時(shí)間運(yùn)行內(nèi)存上漲異常幀殘留緩沖區(qū)錯(cuò)誤幀及時(shí)清理 buffer6.2 幾個(gè)別人不一定會告訴你的實(shí)操心得第一永遠(yuǎn)打印原始十六進(jìn)制。不管協(xié)議多復(fù)雜先用bytes.hex()把收發(fā)都打出來肉眼核對幀頭幀尾和 CRC 位置。我見過太多人對著協(xié)議文檔改代碼改一下午其實(shí)問題就是某一幀多了一個(gè)字節(jié)打印出來一眼就看見。第二模擬工具的日志級別做成可調(diào)。平時(shí)只記關(guān)鍵事件復(fù)現(xiàn)問題的時(shí)候打開逐幀日志。逐幀日志一開每秒幾千行長時(shí)間掛機(jī)會把磁盤寫滿所以一定要能關(guān)。第三給每個(gè)用例編號并寫進(jìn)注釋。回歸失敗時(shí)腳本輸出用例編號人能直接從報(bào)告定位到具體協(xié)議條目比看堆棧有用得多。第四模擬工具的應(yīng)答內(nèi)容不要寫死。至少留一個(gè)配置文件或者命令行參數(shù)讓關(guān)鍵返回值可調(diào)否則每次驗(yàn)證新分支都要改代碼重新跑。這個(gè)習(xí)慣讓我的用例迭代速度提升明顯。最后分享一個(gè)小經(jīng)驗(yàn)把虛擬串口對的建立、模擬從機(jī)啟動(dòng)、上位機(jī)回歸腳本串成一個(gè)一鍵腳本每次代碼改動(dòng)只需要跑一條命令。跑完輸出通過率失敗項(xiàng)自動(dòng)附帶收到的原始幀。這套流程搭好之后串口協(xié)議的驗(yàn)證從“一件麻煩事”變成了“順手就跑一下”的日常操作很多潛在問題就是在這種隨手回歸里被提前揪出來的。 串口模擬工具實(shí)戰(zhàn)：虛擬串口對+Python實(shí)現(xiàn)協(xié)議自動(dòng)化測試
1. 從“板子還在路上”說起串口模擬工具到底解決什么問題手上只有一份協(xié)議文檔硬件板子還在物流途中上位機(jī)代碼卻要趕在明天上午聯(lián)調(diào)完——這種場面我經(jīng)歷過不止一次。串口模擬工具就是給這種場景準(zhǔn)備的救火隊(duì)員它不產(chǎn)生真實(shí)的 TTL 電平也不占用你機(jī)箱上的物理 USB 口而是在操作系統(tǒng)層面虛擬出一對或多對串口讓上位機(jī)軟件以為自己插上了一根 USB 轉(zhuǎn) TTL 線實(shí)際上線的另一端坐著一個(gè)能按協(xié)議回?cái)?shù)據(jù)的程序。串口測試?yán)镒詈臅r(shí)間的從來不是收發(fā)動(dòng)作本身而是“等硬件”“復(fù)現(xiàn)偶發(fā)異?！薄膀?yàn)證邊界幀”這三件事而模擬工具恰好能把這三點(diǎn)都扳回來。先說清楚它不是什么。模擬工具替代不了電磁兼容測試、替代不了真實(shí)的 RS485 總線負(fù)載、替代不了串口燒寫過程中那頭具體的 MCU。但它能把 80% 的協(xié)議邏輯驗(yàn)證、幀格式校驗(yàn)、異常分支覆蓋放在硬件到貨之前完成剩下 20% 的硬件相關(guān)特性再上真板子收尾。這個(gè)分工一旦劃清楚整個(gè)項(xiàng)目的節(jié)奏會順很多也不會出現(xiàn)“板子一到手全都在改低級 bug”的尷尬。這篇文章寫給三類人正在做上位機(jī)串口開發(fā)但缺硬件的工程師、需要用自動(dòng)化測試批量回歸串口協(xié)議的測試同學(xué)、以及被CH340 驅(qū)動(dòng)和波特率對不上折磨過的新手。我會從底層通信機(jī)制講到虛擬串口對的建立再給出一套可以直接抄作業(yè)的 Python 模擬工具實(shí)現(xiàn)最后把踩過的坑整理成速查表。文中沒有模棱兩可的“建議考慮”所有參數(shù)和代碼都在我自己的機(jī)器上跑過。1.1 真實(shí)串口調(diào)試最讓人頭疼的三個(gè)卡點(diǎn)第一個(gè)卡點(diǎn)是硬件不在位。嵌入式項(xiàng)目里上位機(jī)和下位機(jī)經(jīng)常是兩個(gè)團(tuán)隊(duì)并行推進(jìn)下位機(jī)固件還在調(diào)傳感器上位機(jī)的通信模塊只能干等。等板子到了兩邊的 bug 混在一起到底是協(xié)議解析寫錯(cuò)了還是對方發(fā)送時(shí)序有偏差排查起來互相甩鍋。第二個(gè)卡點(diǎn)是偶發(fā)異常難復(fù)現(xiàn)。比如某條命令在連續(xù)發(fā)送 10 萬次后偶發(fā)回復(fù)錯(cuò)幀真實(shí)硬件上你要掛機(jī)跑一整天才能撞上一次。模擬工具可以直接構(gòu)造“第 99999 幀故意延遲 200ms 回復(fù)”這種劇本幾秒鐘就能復(fù)現(xiàn)定位效率完全不是一個(gè)量級。第三個(gè)卡點(diǎn)是邊界用例成本高。超長幀、校驗(yàn)錯(cuò)、幀頭粘連、半包數(shù)據(jù)、粘包數(shù)據(jù)這些異常幀用真硬件注入非常別扭要么改固件專門加測試分支要么用信號發(fā)生器硬湊。虛擬串口這一側(cè)寫代碼隨意構(gòu)造字節(jié)流想發(fā)什么發(fā)什么測完刪掉即可不留任何副作用。注意模擬工具驗(yàn)證的是“協(xié)議邏輯與上位機(jī)魯棒性”它無法證明你的硬件電路在強(qiáng)干擾下不掉線也無法驗(yàn)證 RS485 收發(fā)切換的時(shí)序余量。這兩塊必須留給真板子。1.2 模擬工具的能力邊界先劃清楚再動(dòng)手我見過有人指望模擬工具能測出電源紋波導(dǎo)致的串口通信誤碼這是方向錯(cuò)了。模擬工具體驗(yàn)的是純軟件鏈路從應(yīng)用程序緩沖區(qū)到虛擬驅(qū)動(dòng)緩沖區(qū)中間沒有任何模擬信號。它的價(jià)值集中在數(shù)據(jù)鏈路層以上的邏輯幀結(jié)構(gòu)、命令字、長度域、校驗(yàn)算法、超時(shí)重傳、多幀拼接、狀態(tài)機(jī)跳轉(zhuǎn)。反過來說凡是和電氣特性、uart 串口通信電平、共模干擾、地環(huán)路相關(guān)的測試模擬工具一律不碰。把邊界寫進(jìn)測試計(jì)劃的“適用范圍”一欄后面評審時(shí)不會有人拿這個(gè)來質(zhì)疑測試充分性。我自己的習(xí)慣是在測試報(bào)告開頭明確寫一行本次驗(yàn)證覆蓋協(xié)議層物理層特性另行安排。還有一個(gè)容易忽略的邊界USB 轉(zhuǎn)串口芯片帶來的驅(qū)動(dòng)層行為。CH340、CP2102、FT232 這些芯片在驅(qū)動(dòng)層面有各自的緩沖區(qū)大小和超時(shí)特性虛擬串口對是沒有這些特性的。所以在模擬環(huán)境里跑通的超時(shí)參數(shù)搬到真板子上可能要重新標(biāo)定一次這一點(diǎn)后面第 6 節(jié)會詳細(xì)講。2. 串口通信的底層邏輯與模擬工具的介入點(diǎn)要明白模擬工具為什么能騙過上位機(jī)得先知道一個(gè)字節(jié)是怎么從代碼走到線上的。應(yīng)用程序調(diào)用 write 把一串字節(jié)交給內(nèi)核串口驅(qū)動(dòng)驅(qū)動(dòng)把它推到 UART 控制器的發(fā)送 FIFO硬件再按波特率一位一位地把電平翻轉(zhuǎn)出去。接收方向反過來起始位觸發(fā)采樣移位寄存器攢滿 8 位就產(chǎn)生接收中斷驅(qū)動(dòng)讀走數(shù)據(jù)放進(jìn)緩沖區(qū)應(yīng)用程序再 read 出來。波特率決定了每一位的時(shí)間寬度。115200bps 意味著每位約 8.68 微秒一個(gè)標(biāo)準(zhǔn) 10 位幀1 起始 8 數(shù)據(jù) 1 停止大約 86.8 微秒。這個(gè)數(shù)字在模擬環(huán)境里沒有物理意義但它決定了上位機(jī)的超時(shí)閾值該怎么算——比如等待一個(gè) 20 字節(jié)的回復(fù)理論傳輸時(shí)間約 1.74 毫秒考慮到調(diào)度抖動(dòng)超時(shí)設(shè) 50 到 100 毫秒比較從容。2.1 一條數(shù)據(jù)從應(yīng)用程序到虛擬串口對的路徑在 Linux 下虛擬串口對由偽終端pty實(shí)現(xiàn)。socat 創(chuàng)建兩個(gè)配對的 pty 設(shè)備節(jié)點(diǎn)比如 /dev/pts/3 和 /dev/pts/4寫進(jìn)其中一個(gè)的數(shù)據(jù)會從另一個(gè)讀出來行為上和一根交叉連接的串口線完全一致。上位機(jī)打開 /dev/pts/3模擬程序打開 /dev/pts/4雙方都以為自己在和真實(shí)硬件說話。Windows 下沒有 pty 這套機(jī)制靠的是虛擬串口驅(qū)動(dòng)比如開源的 com0com 或者商用軟件里的對應(yīng)功能。它注冊一對 COM 口例如 COM10 和 COM11驅(qū)動(dòng)層直接把寫入 COM10 的數(shù)據(jù)轉(zhuǎn)發(fā)到 COM11 的接收緩沖。上位機(jī)打開 COM10模擬程序打開 COM11鏈路就通了。要注意這兩個(gè)端口號必須是成對創(chuàng)建的單獨(dú)一個(gè)虛擬 COM 口沒有任何對端打開后會一直 read 超時(shí)。Mac 下依然走 pty 那套socat 或者自帶的 screen 配合 pty 都能用路徑形如 /dev/ttys00x。三套系統(tǒng)的實(shí)現(xiàn)機(jī)制不同但對上位機(jī)而言都是“一個(gè)普通串口”這就是模擬方案通用性的根源——不對上層暴露任何差異。2.2 模擬工具到底站在協(xié)議棧的哪一層模擬工具站在“字符設(shè)備之上、應(yīng)用協(xié)議之下”。它不做電氣層的比特翻轉(zhuǎn)但要完整承擔(dān)字節(jié)流的組織與解析。這意味著兩件事必須由我們自己負(fù)責(zé)一是分幀二是應(yīng)答時(shí)序。分幀是把連續(xù)字節(jié)流按協(xié)議切成一條條完整報(bào)文應(yīng)答時(shí)序是決定收到命令后立即回復(fù)還是延遲回復(fù)、分幾次回復(fù)、故意錯(cuò)發(fā)一次再補(bǔ)發(fā)正確幀。我傾向把這層邏輯寫成一個(gè)獨(dú)立的“協(xié)議引擎”模塊和串口收發(fā)模塊解耦。串口收發(fā)模塊只負(fù)責(zé) open、read、write、close協(xié)議引擎只負(fù)責(zé)字節(jié)數(shù)組進(jìn)、字節(jié)數(shù)組出。好處是這套引擎既能在虛擬串口上跑也能在真串口上跑將來還能接到網(wǎng)絡(luò) Socket 或者 MQTT 上做虛擬串口軟件式的轉(zhuǎn)發(fā)復(fù)用率極高。這個(gè)分層是在被兩三個(gè)項(xiàng)目折磨之后才定下來的一開始全塞在一個(gè)腳本里改起來非常痛苦。3. 方案選型虛擬串口對、腳本模擬、硬件仿真三種路線怎么選市面上的方案大致分三類沒有絕對優(yōu)劣取決于你要驗(yàn)證什么、團(tuán)隊(duì)在什么系統(tǒng)上開發(fā)。選錯(cuò)路線最典型的后果是時(shí)間花在折騰工具本身而不是驗(yàn)證業(yè)務(wù)協(xié)議。第一類是虛擬串口對 自研模擬程序。底層用 socat 或 com0com 建立成對端口上層自己寫 Python 或 C# 程序?qū)崿F(xiàn)協(xié)議應(yīng)答。靈活度最高能精確控制每一幀的時(shí)序和內(nèi)容異常注入想怎么玩怎么玩。代價(jià)是要自己寫代碼前期投入大概一天。第二類是現(xiàn)成的串口調(diào)試助手。XCOM、SSCOM、友善串口助手這類工具都支持定時(shí)發(fā)送、十六進(jìn)制收發(fā)、多條指令輪發(fā)。它們適合手動(dòng)驗(yàn)證單條命令但要做“收到 A 命令后按條件回復(fù) B 幀”這種交互邏輯就很吃力基本只能靠人工點(diǎn)發(fā)送。做回歸測試時(shí)不推薦效率太低。第三類是帶腳本的增強(qiáng)型模擬軟件可以理解為調(diào)試助手加了一個(gè)規(guī)則引擎收到指定幀自動(dòng)觸發(fā)回復(fù)。上手快不用寫代碼但復(fù)雜協(xié)議比如帶變長負(fù)載和 CRC 校驗(yàn)的配置起來反而繞。適合協(xié)議簡單、用例不多的場景。3.1 三種路線的橫向?qū)Ρ葘Ρ染S度虛擬串口對 自研程序串口調(diào)試助手手動(dòng)帶腳本的增強(qiáng)模擬軟件協(xié)議復(fù)雜度承載能力高任意邏輯低僅手動(dòng)中受規(guī)則引擎限制異常幀注入完全可控手動(dòng)拼十六進(jìn)制部分支持自動(dòng)化回歸天然支持不支持有限支持前期投入約 1 人天幾乎為零約 2 小時(shí)長期維護(hù)成本低代碼即文檔高全靠人工中適合場景協(xié)議測試、持續(xù)集成臨時(shí)抓包、單條驗(yàn)證快速原型、輕量驗(yàn)證從表里能看出如果項(xiàng)目周期超過兩周且需要回歸虛擬串口對加自研程序幾乎是唯一劃算的選擇。前期多花的那一天會在后續(xù)每次改協(xié)議、每次回歸里加倍省回來。我做過一個(gè)小統(tǒng)計(jì)某項(xiàng)目用自研模擬工具后通信模塊的單輪回歸時(shí)間從人工 40 分鐘壓到腳本 90 秒改了 11 輪協(xié)議就省出了整整一天。3.2 選型時(shí)最容易忽略的兩個(gè)隱藏成本第一個(gè)隱藏成本是跨平臺。如果團(tuán)隊(duì)里有人用 Windows、有人用 Linux虛擬串口對的建立方式完全不同模擬程序的串口路徑要參數(shù)化不能寫死 /dev/pts/3。我通常把端口名做成配置文件項(xiàng)或命令行參數(shù)甚至用環(huán)境變量注入避免換臺機(jī)器就報(bào)“找不到串口”。第二個(gè)隱藏成本是端口號漂移。Linux 下 pty 的編號是動(dòng)態(tài)分配的這次是 /dev/pts/3下次可能是 /dev/pts/7。解決辦法是 socat 輸出創(chuàng)建結(jié)果后程序解析或者干脆用固定的符號鏈接指向它。Windows 下 com0com 分配的是固定 COM 號相對省心但偶爾會被系統(tǒng)占用沖突。這些小事不提前想第一次跑就會卡住。提示把“建立虛擬串口對”這一步單獨(dú)寫成一個(gè)啟動(dòng)腳本成功后再拉起模擬程序中間加一個(gè)端口就緒的探測循環(huán)。否則容易出現(xiàn)上位機(jī)先打開、pty 還沒創(chuàng)建完的競態(tài)。4. 手把手搭建用 Python 寫一個(gè)可配置的串口模擬工具下面這套實(shí)現(xiàn)是我目前項(xiàng)目里在用的簡化版去掉業(yè)務(wù)相關(guān)代碼后大約兩百行跑在 Python 3.8 以上依賴只有 pyserial。它的設(shè)計(jì)目標(biāo)是一套協(xié)議引擎能掛在虛擬串口上也能掛在真串口上支持變長幀、CRC16 校驗(yàn)、按命令字分派處理函數(shù)、可控的應(yīng)答延遲和錯(cuò)誤注入。先明確協(xié)議幀格式這個(gè)格式是我按常見工業(yè)協(xié)議抽象出來的你可以按自己的實(shí)際協(xié)議替換字段含義------------------------------------------------- | 幀頭 | 長度 | 命令字 | 數(shù)據(jù)區(qū) | CRC16 | 幀尾 | | 2 字節(jié) | 1 字節(jié) | 1 字節(jié) | N 字節(jié) | 2 字節(jié) | 1 字節(jié) | | AA 55 | len | cmd | ... | 低字節(jié)在前 | 0D | -------------------------------------------------長度域統(tǒng)計(jì)的是從命令字到數(shù)據(jù)區(qū)結(jié)束的字節(jié)數(shù)CRC 計(jì)算范圍是長度域、命令字、數(shù)據(jù)區(qū)不包含幀頭幀尾。這套定義在解析時(shí)要嚴(yán)格遵守否則半包拼接永遠(yuǎn)對不上。4.1 環(huán)境準(zhǔn)備與依賴安裝Linux 下不需要額外安裝虛擬串口驅(qū)動(dòng)裝 socat 即可# Debian/Ubuntu 系 sudo apt-get install socat # 驗(yàn)證版本 socat -VWindows 下推薦用開源的 com0com安裝后打開它的 Setup 圖形界面添加一對端口例如 COM10 和 COM11勾選“use Ports class”可以偽裝成標(biāo)準(zhǔn)串口設(shè)備。裝完后在設(shè)備管理器里應(yīng)該能看到這對端口。如果設(shè)備的串口燒寫失敗、提示找不到端口八成是驅(qū)動(dòng)沒簽名或者被系統(tǒng)攔了這類CH340 串口驅(qū)動(dòng)相關(guān)的問題在 Windows 上很常見后面第 6 節(jié)會專門說。Python 側(cè)只需要一個(gè)庫pip install pyserial驗(yàn)證 pyserial 能否枚舉端口python -m serial.tools.list_ports這一步能列出你建好的虛擬端口就說明驅(qū)動(dòng) OK。4.2 建立虛擬串口對并確認(rèn)鏈路Linux/Mac 下用一條命令建立成對 pty并把兩個(gè)端口名打印出來socat -d -d pty,raw,echo0,link/tmp/ttyV0 pty,raw,echo0,link/tmp/ttyV1執(zhí)行后會停在終端不返回這是正常的它作為守護(hù)進(jìn)程持續(xù)轉(zhuǎn)發(fā)數(shù)據(jù)。另開一個(gè)終端檢查ls -l /tmp/ttyV0 /tmp/ttyV1兩個(gè)符號鏈接會指向?qū)嶋H的 /dev/pts/N。這種用固定符號鏈接的做法解決了前面說的端口號漂移問題程序里直接填 /tmp/ttyV0 即可。參數(shù)里 raw 表示不做任何字符轉(zhuǎn)換echo0 表示不回顯這兩個(gè)必須加否則你會看到一個(gè)端口發(fā)出去的數(shù)據(jù)從自己這里讀回來誤以為是協(xié)議 bug。Windows 下端口就是 COM10 和 COM11無需命令模擬程序開 COM11上位機(jī)開 COM10。4.3 核心代碼幀解析與命令分派先寫 CRC16-MODBUS這個(gè)算法在工業(yè)設(shè)備里出現(xiàn)頻率極高低字節(jié)在前發(fā)送def crc16_modbus(data: bytes) - int: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc再寫一個(gè)帶環(huán)形緩沖的解析器這是整個(gè)工具里最容易寫錯(cuò)的部分。很多人一上來就對 read 到的整塊數(shù)據(jù)切幀遇到半包立刻崩。正確做法是維護(hù)一個(gè) bytearray每次把新數(shù)據(jù)追加進(jìn)去然后循環(huán)嘗試切出一條完整幀切不出來就等著class FrameParser: HEAD b\xAA\x55 TAIL b\x0D def __init__(self): self.buf bytearray() def feed(self, chunk: bytes): self.buf.extend(chunk) frames [] while True: frame self._try_extract() if frame is None: break frames.append(frame) return frames def _try_extract(self): # 找?guī)^ idx self.buf.find(self.HEAD) if idx 0: # 沒有幀頭只保留最后一個(gè)字節(jié)防跨包 if len(self.buf) 1: del self.buf[:-1] return None if idx 0: del self.buf[:idx] # 丟棄幀頭前的垃圾數(shù)據(jù) # 幀頭 長度域至少 3 字節(jié) if len(self.buf) 3: return None length self.buf[2] total 2 1 length 2 1 # 頭 長 體 CRC 尾 if len(self.buf) total: return None candidate bytes(self.buf[:total]) if candidate[-1] ! self.TAIL[0]: del self.buf[:2] return None calc crc16_modbus(candidate[2:3 length]) recv candidate[3 length] | (candidate[4 length] 8) if calc ! recv: del self.buf[:2] return None del self.buf[:total] return candidate這里有個(gè)細(xì)節(jié)值得強(qiáng)調(diào)校驗(yàn)失敗時(shí)我只丟棄兩個(gè)字節(jié)的幀頭而不是整幀丟掉。原因是數(shù)據(jù)流里可能出現(xiàn)“假幀頭”如果按偽長度直接跳過一整幀真實(shí)的幀頭可能就被誤吞了。逐字節(jié)滑動(dòng)重新找?guī)^魯棒性最好。當(dāng)然這會帶來一點(diǎn)點(diǎn)重解析開銷但對串口這種低速鏈路完全無所謂。接下來是模擬從機(jī)的收發(fā)主循環(huán)命令字分派用字典import serial import time class MockSlave: def __init__(self, port, baudrate115200, delay0.01, inject_errorFalse): self.ser serial.Serial( portport, baudratebaudrate, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout0.02, ) self.parser FrameParser() self.delay delay self.inject_error inject_error self.counter 0 self.handlers { 0x01: self.handle_read_status, 0x02: self.handle_write_param, 0x03: self.handle_heartbeat, } def build_frame(self, cmd: int, payload: bytes) - bytes: body bytes([len(payload) 1, cmd]) payload crc crc16_modbus(body) return b\xAA\x55 body bytes([crc 0xFF, crc 8]) b\x0D def handle_read_status(self, payload: bytes) - bytes: return bytes([0x00, 0x64, 0x01]) # 狀態(tài)正常, 溫度, 通道 def handle_write_param(self, payload: bytes) - bytes: return bytes([0x00]) def handle_heartbeat(self, payload: bytes) - bytes: self.counter 1 return bytes([0x00, self.counter 0xFF]) def run_forever(self): while True: chunk self.ser.read(256) if not chunk: continue for frame in self.parser.feed(chunk): cmd frame[3] length frame[2] payload frame[4:3 length] handler self.handlers.get(cmd) if handler is None: resp_payload bytes([0x01]) # 不支持的命令 else: resp_payload handler(payload) time.sleep(self.delay) if self.inject_error and self.counter % 7 0: resp self.build_frame(cmd, resp_payload)[:-4] # 故意截?cái)?else: resp self.build_frame(cmd, resp_payload) self.ser.write(resp) if __name__ __main__: slave MockSlave(/tmp/ttyV1, baudrate115200, delay0.005) slave.run_forever()這段代碼里幾個(gè)參數(shù)都是可調(diào)的delay 控制應(yīng)答延遲用來測上位機(jī)的超時(shí)邏輯inject_error 打開后每 7 幀故意發(fā)一條殘缺幀驗(yàn)證上位機(jī)對錯(cuò)幀的處理。實(shí)測把 delay 調(diào)到 0.2 秒時(shí)我那份超時(shí)閾值設(shè) 100 毫秒的上位機(jī)立刻報(bào)超時(shí)并重發(fā)說明超時(shí)機(jī)制工作正常。4.4 配一個(gè)自動(dòng)化回歸腳本收尾模擬從機(jī)跑起來后上位機(jī)的驗(yàn)證就可以完全自動(dòng)化。下面這段腳本模擬上位機(jī)行為逐條發(fā)命令、斷言回復(fù)import serial import time import pytest PORT_MASTER /tmp/ttyV0 def build(cmd, payloadb): body bytes([len(payload) 1, cmd]) payload crc crc16_modbus(body) return b\xAA\x55 body bytes([crc 0xFF, crc 8]) b\x0D pytest.fixture def master(): ser serial.Serial(PORT_MASTER, 115200, timeout0.1) yield ser ser.close() def read_one(ser): parser FrameParser() deadline time.time() 1.0 while time.time() deadline: frames parser.feed(ser.read(256)) if frames: return frames[0] return None def test_read_status(master): master.write(build(0x01)) resp read_one(master) assert resp is not None assert resp[3] 0x01 assert resp[4] 0x00 def test_heartbeat_increments(master): seen set() for _ in range(5): master.write(build(0x03)) resp read_one(master) assert resp is not None seen.add(resp[4]) assert len(seen) 5 # 每個(gè)心跳計(jì)數(shù)應(yīng)不同用 pytest 跑起來就是一條命令的事配合持續(xù)集成可以做到每次提交自動(dòng)回歸。這套東西搭好之后協(xié)議改動(dòng)的驗(yàn)證成本幾乎降到零。5. 測試結(jié)論怎么來的功能、邊界、壓力三類用例設(shè)計(jì)工具能跑通只是第一步真正決定測試結(jié)論可信度的是用例設(shè)計(jì)。我習(xí)慣把串口類用例拆成三層功能層保證主流程對邊界層保證異常輸入不崩壓力層保證長時(shí)間運(yùn)行不泄漏不卡死。三層都過了才敢在報(bào)告里寫“通過”。5.1 功能用例把每條命令的正常路徑走一遍功能層最直接針對協(xié)議文檔里每一條命令字構(gòu)造合法請求斷言響應(yīng)字段含義正確。這里有兩個(gè)細(xì)節(jié)值得展開。一是響應(yīng)內(nèi)容要覆蓋所有分支。比如讀狀態(tài)命令正常返回 0x00但設(shè)備可能處于告警、離線、初始化中等狀態(tài)模擬工具應(yīng)該能按參數(shù)切換返回不同狀態(tài)碼讓上位機(jī)的狀態(tài)機(jī)每個(gè)分支都被執(zhí)行到。如果模擬工具只會返回一種狀態(tài)上位機(jī)的告警處理邏輯永遠(yuǎn)是沒測過的死代碼。二是請求參數(shù)要有代表性組合。寫參數(shù)命令往往有多個(gè)字段全用 0 和全用最大值是最沒營養(yǎng)的測法。我的做法是選邊界值加隨機(jī)值混合字段 A 取最小值、字段 B 取最大值、字段 C 取隨機(jī)中間值跑幾十組。隨機(jī)數(shù)種子固定保證失敗可復(fù)現(xiàn)。這塊我在一個(gè)項(xiàng)目里吃過教訓(xùn)寫參數(shù)命令的校驗(yàn)邏輯只測了合法值上線后遇到設(shè)備端傳回全 0xFF 的非法參數(shù)直接解析越界。補(bǔ)上邊界用例只花了半小時(shí)省下的現(xiàn)場排查時(shí)間按天算。5.2 邊界與異常用例丑幀才是真考驗(yàn)邊界層是模擬工具真正的主場。下面這些幀類型建議全部覆蓋異常類型構(gòu)造方法期望上位機(jī)行為半包幀先發(fā)前半截延遲 50ms 再發(fā)后半截正確拼接不誤判為錯(cuò)幀粘包幀兩條完整幀一次性連續(xù)發(fā)送完整切分成兩條都正確處理校驗(yàn)錯(cuò)故意把 CRC 改錯(cuò)丟棄該幀不回應(yīng)答不崩潰長度域超限length 填一個(gè)遠(yuǎn)超實(shí)際的巨大值等待超時(shí)后丟棄緩沖區(qū)不無限增長幀頭粘連幀頭后緊跟另一幀頭丟棄前段垃圾從第二個(gè)幀頭重新解析未知命令字cmd 填協(xié)議未定義值返回不支持錯(cuò)誤碼或按約定忽略非法幀尾幀尾字節(jié)被篡改判定為無效幀重新同步注意長度域超限這條最容易埋雷。如果解析器按 length 預(yù)分配緩沖區(qū)一個(gè)偽造的巨大 length 就能讓內(nèi)存爆掉。我的做法是給 length 設(shè)一個(gè)上限常量超過直接丟棄當(dāng)前候選幀并滑動(dòng)重新同步。異常用例還有一類是時(shí)序類比如兩幀間隔小于設(shè)備端處理周期、應(yīng)答延遲超過上位機(jī)超時(shí)閾值、上位機(jī)連發(fā)三幀不等回復(fù)。這些用模擬工具的 delay 參數(shù)就能構(gòu)造真硬件上反而難精確控制。5.3 壓力與長穩(wěn)跑夠時(shí)長再下結(jié)論壓力層關(guān)注三件事吞吐、內(nèi)存、穩(wěn)定性。吞吐上讓模擬工具以最高頻率收幀回幀持續(xù)跑一小時(shí)觀察上位機(jī)的處理隊(duì)列有沒有積壓、有沒有丟幀。串口本身速度有限115200bps 下理論上限也就每秒一千多幀短幀一般跑不滿瓶頸往往在上位機(jī)的解析線程。內(nèi)存上重點(diǎn)看解析緩沖區(qū)會不會隨錯(cuò)誤幀增長。如果每收到一條校驗(yàn)錯(cuò)幀就多留一段垃圾在 buffer 里跑一晚上內(nèi)存就上去了。驗(yàn)證方法很簡單讓模擬工具持續(xù)發(fā)錯(cuò)幀跑兩小時(shí)同時(shí)監(jiān)控上位機(jī)進(jìn)程的常駐內(nèi)存曲線應(yīng)該是平的。穩(wěn)定性上我一般設(shè)置一個(gè) 24 小時(shí)長穩(wěn)模擬工具按腳本隨機(jī)組合正常幀和異常幀上位機(jī)持續(xù)運(yùn)行不重啟。跑完之后檢查有無異常退出、有無句柄泄漏、日志里錯(cuò)誤率是否在預(yù)期范圍。這套組合拳跑下來測試結(jié)論才站得住腳。6. 踩坑記錄與常見問題速查這一節(jié)是我最想分享的部分因?yàn)橄旅孢@些問題幾乎每一個(gè)都讓我在現(xiàn)場多待了半小時(shí)以上。先說CH340 串口驅(qū)動(dòng)那點(diǎn)事。Windows 10 之后的系統(tǒng)對未簽名驅(qū)動(dòng)卡得很嚴(yán)有些老版本的 CH340 驅(qū)動(dòng)裝上后設(shè)備管理器能認(rèn)到端口但一打開就報(bào)“拒絕訪問”或者干脆收不到數(shù)據(jù)。遇到這種情況先卸載舊驅(qū)動(dòng)重啟再裝官網(wǎng)最新版。如果還是不行檢查設(shè)備管理器里該端口是否被標(biāo)記了黃色感嘆號有的話右鍵看錯(cuò)誤碼。另一個(gè)高頻坑是同一個(gè) CH340 芯片被兩套驅(qū)動(dòng)搶占表現(xiàn)為端口能打開但讀寫全是 0 字節(jié)設(shè)備管理器里能看到兩個(gè)條目刪掉多余的那個(gè)即可。再說串口接收數(shù)據(jù)丟失。Linux 下偶爾丟數(shù)據(jù)八成是讀取線程阻塞太久驅(qū)動(dòng)緩沖區(qū)溢出。解決無非兩條加大驅(qū)動(dòng)緩沖區(qū)stty 里的設(shè)置或者加快讀取頻率。我習(xí)慣開一個(gè)專職讀線程用最小 timeout 循環(huán) read讀到就塞進(jìn)隊(duì)列業(yè)務(wù)邏輯在另一個(gè)線程從隊(duì)列取寫日志這種耗時(shí)操作絕對不能在讀線程里做。這條經(jīng)驗(yàn)幫我解決了三次“偶發(fā)丟包”。還有串口關(guān)閉時(shí)的資源釋放。很多人寫程序只管 open 不管 close程序退出時(shí)端口沒釋放下次打開報(bào)“設(shè)備忙”。正確做法是把串口對象的關(guān)閉放進(jìn) finally 或者上下文管理器。如果還是遇到占用用 lsof 查一下哪個(gè)進(jìn)程還開著它Windows 下用資源監(jiān)視器搜句柄。6.1 高頻問題速查表現(xiàn)象可能原因排查與解決端口打不開提示被占用上個(gè)進(jìn)程未釋放lsof 查占用進(jìn)程殺進(jìn)程或重啟打開成功但收不到數(shù)據(jù)端口對端沒打開 / 端口配錯(cuò)對確認(rèn)虛擬串口對的另一端已連接收到自己發(fā)出的數(shù)據(jù)未關(guān)閉回顯pty 建鏈時(shí)加 echo0、raw數(shù)據(jù)偶爾丟失讀取線程阻塞緩沖溢出獨(dú)立讀線程最小超時(shí)循環(huán)讀亂碼波特率、校驗(yàn)位、停止位不一致逐項(xiàng)核對優(yōu)先懷疑波特率校驗(yàn)頻繁失敗分幀邏輯有誤或字節(jié)序搞反打印原始 hex核對 CRC 字節(jié)序虛擬端口下一臺機(jī)器找不到pty 編號漂移用符號鏈接固定路徑長時(shí)間運(yùn)行內(nèi)存上漲異常幀殘留緩沖區(qū)錯(cuò)誤幀及時(shí)清理 buffer6.2 幾個(gè)別人不一定會告訴你的實(shí)操心得第一永遠(yuǎn)打印原始十六進(jìn)制。不管協(xié)議多復(fù)雜先用bytes.hex()把收發(fā)都打出來肉眼核對幀頭幀尾和 CRC 位置。我見過太多人對著協(xié)議文檔改代碼改一下午其實(shí)問題就是某一幀多了一個(gè)字節(jié)打印出來一眼就看見。第二模擬工具的日志級別做成可調(diào)。平時(shí)只記關(guān)鍵事件復(fù)現(xiàn)問題的時(shí)候打開逐幀日志。逐幀日志一開每秒幾千行長時(shí)間掛機(jī)會把磁盤寫滿所以一定要能關(guān)。第三給每個(gè)用例編號并寫進(jìn)注釋。回歸失敗時(shí)腳本輸出用例編號人能直接從報(bào)告定位到具體協(xié)議條目比看堆棧有用得多。第四模擬工具的應(yīng)答內(nèi)容不要寫死。至少留一個(gè)配置文件或者命令行參數(shù)讓關(guān)鍵返回值可調(diào)否則每次驗(yàn)證新分支都要改代碼重新跑。這個(gè)習(xí)慣讓我的用例迭代速度提升明顯。最后分享一個(gè)小經(jīng)驗(yàn)把虛擬串口對的建立、模擬從機(jī)啟動(dòng)、上位機(jī)回歸腳本串成一個(gè)一鍵腳本每次代碼改動(dòng)只需要跑一條命令。跑完輸出通過率失敗項(xiàng)自動(dòng)附帶收到的原始幀。這套流程搭好之后串口協(xié)議的驗(yàn)證從“一件麻煩事”變成了“順手就跑一下”的日常操作很多潛在問題就是在這種隨手回歸里被提前揪出來的。