在雲端 Mac 自動化 Bonjour 服務探索回歸測試

遠端辦公時，應用程式能透過明確的主機名稱與連接埠建立連線，並不代表 Bonjour 服務探索也能正常運作。列印、投放畫面、偵錯代理程式或區域網路協作工具通常依賴 mDNS；一旦服務類型、TXT 記錄或網路介面發生變化，介面上可能只會顯示「附近裝置消失」。這類問題適合在雲端 Mac 進行通訊協定層級的回歸測試：先註冊臨時服務，再驗證瀏覽、解析與退出清理，而不是等待實體裝置偶發失敗。

先界定測試邊界

Bonjour 通常透過 UDP 5353，在鏈路本地範圍傳送 mDNS 多點傳送封包。即使 TCP 連接埠可連線，mDNS 也不會自然穿越路由器、一般 SSH 通道或遠端桌面連線。因此，雲端測試應拆分成兩個層級：

1. 在同一個 macOS 節點驗證註冊、瀏覽、SRV 解析與 TXT 記錄。
2. 另行在目標區域網路內測試實體裝置互通，驗證交換器、無線網路與多點傳送原則。

第一層適合納入每次提交都會執行的 CI，可發現服務類型拼寫錯誤、連接埠錯誤、中繼資料缺漏，以及程序未退出等問題。第二層屬於網路驗收，不能以第一層的結果取代。

Bonjour 測試通過，只能證明服務探索契約在目前測試邊界內成立，無法證明多點傳送已跨越遠端網路邊界。

建議為產品配置專用的服務類型，例如 _myapp-test._tcp。不要借用 _http._tcp，否則測試節點上的其他服務可能混入結果。執行個體名稱也不能固定，應包含本次工作的唯一識別碼。

使用 dns-sd 建立最小閉環

macOS 內建 dns-sd，無須額外安裝相依套件。以下指令碼會啟動臨時 HTTP 服務，先開始瀏覽，再註冊 Bonjour 執行個體，最後解析該執行個體並檢查 TXT 內容。可將它存放在儲存庫的 ci/test-bonjour.sh。

#!/bin/bash
set -euo pipefail

RUN_ID="${CI_RUN_ID:-$(date +%s)}"
INSTANCE="vmcache-${RUN_ID}"
TYPE="_myapp-test._tcp"
PORT="${BONJOUR_TEST_PORT:-8088}"
WORK_DIR="$(mktemp -d)"
BROWSE_LOG="$WORK_DIR/browse.log"
RESOLVE_LOG="$WORK_DIR/resolve.log"

HTTP_PID=""
BROWSE_PID=""
REGISTER_PID=""
RESOLVE_PID=""

cleanup() {
  for pid in "$RESOLVE_PID" "$REGISTER_PID" "$BROWSE_PID" "$HTTP_PID"; do
    if [[ -n "$pid" ]]; then
      kill "$pid" 2>/dev/null || true
      wait "$pid" 2>/dev/null || true
    fi
  done
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT INT TERM

python3 -m http.server "$PORT" --bind 0.0.0.0 \
  >"$WORK_DIR/http.log" 2>&1 &
HTTP_PID=$!

dns-sd -B "$TYPE" local. >"$BROWSE_LOG" 2>&1 &
BROWSE_PID=$!

dns-sd -R "$INSTANCE" "$TYPE" local. "$PORT" \
  "path=/" "run=$RUN_ID" >"$WORK_DIR/register.log" 2>&1 &
REGISTER_PID=$!

sleep 4
grep -F "$INSTANCE" "$BROWSE_LOG"

dns-sd -L "$INSTANCE" "$TYPE" local. >"$RESOLVE_LOG" 2>&1 &
RESOLVE_PID=$!
sleep 3
kill "$RESOLVE_PID" 2>/dev/null || true
wait "$RESOLVE_PID" 2>/dev/null || true
RESOLVE_PID=""

grep -E "path=/|run=$RUN_ID" "$RESOLVE_LOG"
grep -E "$PORT" "$RESOLVE_LOG"
curl --fail --silent --show-error "http://127.0.0.1:$PORT/" >/dev/null

瀏覽必須先於註冊啟動，否則執行時間較短的工作可能會錯過新增事件。此處沒有讓 dns-sd 在前景執行，因為瀏覽與解析指令會持續等待；CI 必須主動設定觀察時間，並在時間結束後終止程序。

讓斷言對準服務契約

只檢查執行個體名稱是否出現並不足夠。穩定的回歸測試至少應驗證四個項目：服務類型、執行個體名稱、連接埠與 TXT 記錄。TXT 記錄應只保存探索階段真正需要的低敏感度中繼資料，例如通訊協定版本、功能標記與健康檢查路徑，不應放入權杖、密碼或內部憑證。

建議將通訊協定版本寫成 api=2，功能則寫成 features=sync,preview。測試端應逐項斷言，而不是比較整行輸出。dns-sd 的輸出包含時間與介面資訊，完整行快照很容易隨系統版本變化。

若應用程式會拒絕舊版通訊協定，可再註冊一個 api=1 的執行個體，驗證用戶端確實會忽略它。如此測試涵蓋的是選擇邏輯，而不只是「看見一個名稱」。解析成功後，還應向實際連接埠傳送一次最小請求，避免出現「廣播寫 8088，服務卻監聽 8089」的假通過。

處理平行工作、殘留程序與暴露範圍

同一節點同時執行多個工作時，執行個體名稱與連接埠都必須隔離。在執行個體名稱加入工作編號，只能避免探索結果混淆，無法防止兩個 HTTP 服務搶占同一連接埠。CI 排程器應預先分配連接埠，或在啟動前使用 lsof -nP -iTCP:$PORT -sTCP:LISTEN 檢查是否已被占用。

所有背景程序都必須納入 trap。若斷言失敗後註冊程序仍在執行，下一次測試可能探索到舊的執行個體，形成難以重現的假陽性。清理時應先停止解析與註冊，再停止瀏覽程序與測試服務。

此範例為了完成端對端檢查而監聽所有介面。即使使用獨享雲端 Mac，仍應遵循最小暴露原則：測試連接埠只在受控網路中短暫開啟。不需要網路請求時，可省略 HTTP 服務，只驗證註冊與解析。測試執行前後可分別執行 lsof，確認連接埠沒有殘留的監聽程序。

從失敗輸出定位問題

「瀏覽不到」時，先檢查服務類型是否完全一致，包括開頭的底線與 _tcp 後綴；再檢查註冊程序是否提早退出。能瀏覽但無法解析時，應優先查看執行個體名稱跳脫、網域參數與本機名稱解析。能解析卻無法連上連接埠時，則檢查監聽位址、連接埠占用、防火牆原則與服務啟動順序。

CI 應保存 browse.log、resolve.log 與註冊程序的輸出，但上傳前必須進行去識別化處理。失敗時也應記錄 scutil --get LocalHostName、networksetup -listallhardwareports，以及相關連接埠的 lsof 結果。這些資訊通常足以區分命名問題、介面問題與監聽問題。

在 VMCache 的獨享實體節點上執行這類測試時，也不要假設遠端連線路徑會轉送 mDNS。將通訊協定層級的回歸測試固定在節點內部，並將實體裝置探索放在目標區域網路中另行驗收。兩套結果應分別記錄，才能讓失敗邊界保持清楚且可重複驗證。

常見問題