出廠測試規範

版本：3.4 | 日期：2026-08-28 | 韌體版本：6.0.83（基線） 來源 PRD：docs/prd/prd-factory-test.md(內部文件,未公開) v1.2（結構基線）+ 本文件 v2.1 增量（依 6.0.8 源碼/實機核校） 操作手冊：guide-user-operation-manual.md

v2.9 修訂摘要（2026-08-26,完整重跑驗收流程後）：

• 新增 RG.7(WI-206:Parser「值類型」下拉的 option value 必須對得上韌體 ParserValueType)。該缺陷是走情境 M.3 時抓到的:選「數值」實際會得到布林, 任何非零數字變成 1.0。RG.7 必須斷言 UI 的 option value —— 只用 API 送 parserType:1 驗「韌體會給數值」是抓不到的(韌體本來就對,錯的是前端綁定)。
• 韌體基線 6.0.72 → 6.0.74(WI-206 + WI-197)。
• 全流程重跑結果:test:gate 35/35、test:regression 7/7。

v2.8 修訂摘要（2026-08-26,六張卡修完並實機驗證）：

• test:regression 全數通過,已納入 test:gate:full —— WI-199/200/202/203/205 五個缺陷 已修並經「先紅後綠」驗證(修正前紅、修正後綠,同一台設備同一支測試); WI-201 經查是誤判(WI-170 的寫入佇列早就處理了),已大幅更正該卡。
• 韌體基線 6.0.69 → 6.0.72,經 LAN .mesb OTA 上機,test:gate 35/35。
• 新增 RG.6(WI-205:被拒絕的規則 POST 不得毀掉既有規則)。
• 順帶修好一個從沒被測到的舊 bug:modbusTcpWriteDO 的擴充分支對區域副本取址轉型, Modbus TCP 寫擴充輸出一直沒有作用;已與規則引擎統一用 getExpansionPtr。

v2.7 修訂摘要（2026-08-26,與驗收走查對齊）：

• 新增 npm run test:regression（RG.1–RG.5） —— 驗收走查挖到五個缺陷, 既有閘門一個都沒攔到。這五項是它們的回歸,目前預期紅燈,修好前不列入出貨門檻。
• 修正一個實驗證明的閘門盲點:2B 原本只斷言「TCP 通道」標題可見, 注入 WI-202 的壞值(整份 TCP IO 設定在網頁上消失)後仍 6/6 全綠。 已改為比對「設備上有幾個通道」與「畫面上列出幾個」。
• 環境預設值對齊:factory-env.js 的 DUT_URL 改 .77(有線)、EXPECT_FW 改 6.0.69; package.json 內的舊值一併更新。
• ST.2 改為非破壞性:原本寫死 index: 7,設備規則數 ≥ 8 時會覆蓋現場既有規則 —— 2026-08-26 實際毀掉一條 A2-MQTT亮。已改用「附加位置」(ruleCount)。 該次紅燈同時揭露韌體缺陷 WI-205(回 400 卻仍寫入且不回滾),已補 RG.6 回歸。
• 測試設定來源收斂:先前 6 支 spec 各自寫死 DUT_URL 預設(3 支 .46、3 支 .77), factory-v6 的 EXPECT_FW 還停在 6.0.8 —— 文件卻宣稱「換設備只改一個檔」。 已全部改為從 factory-env.js 取值,那句承諾現在才是真的。
• 已知未處理:package.json 有 4 處明文 broker 密碼(見 WI-204,交付優先暫緩)。

v2.6 修訂摘要（2026-08-20,交付定案版）：

• 測項與腳本對齊(文件先前寫錯)：test:converter 是 5 項 + afterAll 收尾(CV.9 是清理不是測項); test:enable 是 7 項,EN.5(停用 RS485 設備)已從腳本移除 —— 該卡片在畫面上只有「刪除」沒有停用開關, 測一個使用者碰不到的控制項沒有意義;新增 EN.8(停用 Config Server 總開關)。
• 新增章節「本批韌性修正:閘門測不到的那些」:WI-175/180/181/182/183/189 六項, 列出各自「為什麼會壞」與「怎麼驗的」。這張表的用途是改到那塊之前先讀,不是測試清單。
• 新增 npm run test:gate:full:唯讀閘門 + 三支會改動設備狀態的套件一次跑完(交機前用)。 test:gate 維持唯讀語意不變(OTA 後、現場都能安全跑)。
• 本文件已發佈到雲端文件中心 /docs/factory-test.html。

v2.1 修訂摘要（2026-07-16,韌體 6.0.4 → 6.0.8 對齊 + 源碼核校修正）：

• 韌體基線 6.0.4 → 6.0.8：全文版號斷言改 v6.0.8；新增 v6.0.5~6.0.8 能力。
• 新增自動化套件 web/tests/factory-v6.spec.js(13 tests,純 HTTP 唯讀契約)：Phase 0 機型身分 + Phase 6B 遠端診斷 + Phase 2E.6a MQTT 測試契約 + Phase 2E.6b namespace 欄位;npm run test:factory:v6。已對實機 8320(6.0.8)全綠。
• ⚠️ 源碼核校修正欄位名(舊文件錯,自動化已抓出)：
  • /api/diag 實際欄位 = resetReason(非 bootReason)、bootDetail、prevResetReason、bootCount、prevUptimeSec(非 prevUptime)、uptimeSec、rawRsr、fwVersion。
  • /api/system boardModel 值 = 字串 "Opta RS485 (8310)" / "Opta WiFi (8320)"(非 "8310"/"8320");hasWifi 為 boolean;兩者一致。
  • mac 在 /api/config(非 /api/system),格式為冒號大寫(如 A8:61:0A:50:8B:61);對外 topic 12-hex 身分 = 去冒號轉小寫。
• SF965 原生解碼(6.0.8)：H3 新增 VAR_SF965_PV(dataType=8)手動驗證列(需 SF965 硬體;PV@addr4 高 3 byte=值、低 byte=小數點)。
• 離線來源不發假 0(6.0.7)：Phase 4 新增 H3-B3(converter 引用離線 RS485 來源 → 整筆跳過發佈,不送假 0 誤導 MES)。

v2.0 修訂摘要（2026-07-02，韌體 5.9.45 → 6.0.4 對齊）：

• 韌體基線 5.9.45 → 6.0.4：全文版號斷言改 v6.0.4；Phase 0 讀 boardModel/hasWifi/mac。
• 機型維度（8310 / 8320）新增：變體識別從單一「網路變體」擴為 機型 × 網路 二維（8310 無 WiFi / 8320 有 WiFi），來源 = OTP boardInfo().wifi。新增 Phase 4 H8 機型感知 UI 過濾 + 心跳燈（8310 隱藏 WiFi 欄位 + 琥珀燈；8320 露 WiFi + 藍燈）。
• WI-155 平台化（6.0.0）：新增 Phase 2E MQTT 命名空間（projectName+env → {proj}-{env}/gateway/{mac}，留空 = legacy）與 MAC 軟體覆寫 + 90s 試用回退 驗證。
• 遠端診斷（6.0.1）：新增 Phase 6B 遠端維運健檢——/api/log 網頁 Serial Log（/log.html）+ /api/diag 開機原因（BKPSRAM intent 標記）+ 密碼遮罩不外洩。
• RS485 slaveId 持久化（6.0.2）：H3 新增 同型號多台防串台 驗證（各設不同 slaveId ≤32，重開機後不退回陣列位置、不串台）。
• MQTT 測試連線修正（6.0.4）：Phase 2E MQTT 測試改 deferred（POST 202 → GET /api/mqtt/test 輪詢）+ 對已連線同 broker 短路判定；密碼留空 = 用已存密碼。
• 授權撤銷門控（WI-145）：Phase 7 補「撤銷後 TCPIO/MQTT 擋、DIO/管理不擋」的門控驗證。
• MQTT TLS 出廠預設：tlsInsecure=true（業主指定,不驗 CA）——Phase 2E 斷言此為出廠預設,勿改回驗 CA。
• Web 部署模型：index.html 編進韌體、app.js 等 6 資產走 QSPI 熱更——出廠燒錄後首開機須確認網頁完整（非裸 HTML）。
• 附錄 A 補 /api/log、/api/diag、/api/mqtt/test、/api/license/token 端點。

v1.2 修訂摘要（2026-05-27）：

• H3-C 新增 Step 5 校正引導精靈 chain 驗證（4 步驟 + 燈號 + 順序強制，v5.9.130+）
• 附錄 A 補 /api/signals、/api/actions、/api/converter/template 端點
• Phase 7 註記 wizard / wdprobe / watchdog 屬部署佈建非出廠基線
• 相關：spec-mqtt-chain-workflow.md、guide-calibration-wizard.md、guide-failover-resilience.md

v1.1 修訂摘要：

• 韌體版本對齊：5.9.25 → 5.9.45
• 治具校正：Expansion 1 → Expansion 0（array 從 0 起）；YX523R Slave ID 2 → 4
• 新增 MQTT broker fixture（FR-G E2E 必需）與變體識別（ethernet/wifi）
• Phase 結構從 05 擴充為 08，補上 OTA、E2E 業務流、出貨前清理、結果輸出
• 各步驟加上 PRD FR-* 對應 ID + DOM ID 速查表
• 補上 EEPROM DIP+斷電 物理步驟（先前完全漏掉）
• 附錄 C 列 PRD v1.2 已知 UI bug 對工站的影響

#⚡ 先跑自動化閘門(v2.2 起,任何改動後都必須執行)

任何韌體或網頁改動之後,先跑這一道再談其他。 它是唯讀的(不改設備設定), 交機前、OTA 後都能安全執行:

cd web
DUT_URL=http://<設備IP> EXPECT_FW=<版本> npm run test:gate

涵蓋 35 項:頁面渲染(2A–2F)、v6 能力契約、穩定性與持久化(ST.*)。 全數通過才算通過 —— 任何一項紅燈都代表出貨品質有缺口。

另有三支會改動設備狀態、不在閘門內、交機前各跑一次:

npm run test:converter  # ★ MQTT Converter 鏈路(產品主幹),素材自建自清,約 3 分鐘
npm run test:enable     # 啟用/停用機制(⚠ 見下方說明,目前不作為出貨門檻)
npm run test:backup     # ★ 雲端備份/還原閉環(會讓設備重開一次),約 2 分鐘
npm run test:persist    # 真的重開設備,驗設定與統計跨重開存活(約 1 分鐘)
npm run test:factory    # 完整功能測(含 MQTT 佈建,會寫入設定)

#驗收走查回歸(npm run test:regression,RG.1–RG.8)—— 全數通過,已納入出貨門檻

2026-08-25/26 照著驗收單實機走了一遍,挖到五個缺陷。既有出廠閘門一個都沒攔到, 而且不是「剛好沒測到」,是測試的形狀不對 —— 既有測項驗的是「東西在不在、頁面開不開」, 五個缺陷全部落在「內容對不對、值有沒有真的寫進去」。

最直接的證據:把 WI-202 的壞值注回設備(整份 TCP IO 設定在網頁上消失、 顯示「尚無 TCP IO 通道」),factory-pages 依然 6/6 全綠。閘門對它完全無感。

cd web
DUT_URL=http://<設備IP> npm run test:regression

只有 RG.5 預設略過(它會重開設備,要跑帶 RG_ALLOW_REBOOT=1;已實測通過)。

⚠️ 2026-08-27:RG.7 在此之前從來沒有真的執行過。 package.json 的 test:regression 是唯一沒帶 MQTT 環境變數的腳本 (旁邊四個都有),RG.7 因此每次都靜默 skip —— 報表顯示「6 passed」, 看起來很健康。已補齊環境變數,現在會真的跑。

教訓:skipped 不是中性的。一個永遠跳過的測項,和沒有這個測項是一樣的, 但它在報表上長得像有在守。看回歸結果時要同時看 skipped 的數量與原因。

⚠️ 2026-08-28:RG.7 在整套連跑時偶發假紅燈,已修測試方法。 單獨跑綠、RG.5+RG.6+RG.7 最小組合也綠,只有整套跑會紅 —— 而整套跑到 RG.7 時 設備剛經歷 RG.5 的重開加一輪負載。原本的寫法是「建通道 → 固定等 2.5 秒 → 發一次 → 固定等 5 秒 → 讀一次」。MQTT 對「訂閱之前就發出的訊息」沒有補送 —— 設備若還沒訂好新通道的 topic,那則訊息就永遠消失,測試必紅。

已改為週期重發 + 輪詢讀回(45 秒內每三輪重發一次)。這個教訓 acceptance_run.py 早就記過(「通道剛建好時設備可能還沒訂閱」),RG.7 沒套用。

誠實記一筆:那次的錯誤訊息因為輸出被 grep 過濾而遺失,根因是從程式碼推斷、 不是從錯誤訊息實證。修正本身站得住(移除的是本檔已咬過兩次的同一類問題), 但若日後 RG.7 再紅,不要假設就是這個原因。

教訓:跑長時間測試套件時,不要用 grep 過濾輸出 —— 失敗細節只有一次機會保留。

⚠️ RG.2 / RG.3 必須走瀏覽器,不能用 API 並發代替。 這兩個缺陷都在前端 (saveRule 算 index 的邏輯、saveIoName 走 WI-170 的寫入佇列),直接打 API 測到的是我們自己的測試碼,不是產品。初版就是這樣寫的:RG.2 一次就綠(bug 還在)、 RG.3 則「測出」一個其實不存在的缺陷(WI-201 因此大幅更正)。

2026-08-27 追加 RG.8(WI-208)。 業主人工驗收時回報「藍色呼吸燈會卡住, 卡住的時候按鈕就延遲、甚至沒反應」—— 量出主迴圈有 6.8% 的時間完全凍結, 真兇是授權門控每 30 秒重驗一次簽章(663ms)。改為到期驅動後降到約 0.8%。

這一項有實測的鑑別力,不是推論:修正的第一版(v6.0.76)把 expiresAt==0 誤當成「1970 年就過期」,快取完全沒生效 —— 同樣的 200 秒觀測窗裡 gate 重驗 出現 8 次。RG.8 的判準當時會紅。

2026-08-27 更新:七項全綠(RG.5 另以 RG_ALLOW_REBOOT=1 單獨驗過)。 這一輪另外修掉兩個測試自身的問題,兩個都會產生假紅燈: ① RG.2/RG.3 用固定 4 秒等 window.nav 備妥 —— 單獨跑夠,整套跑時設備有負載就不夠 (實測單獨 2 秒即備妥、整套跑時逾時)。已改為輪詢至函式真的存在。 ② RG.3 用譯文 /儲存中|Saving/ 判斷寫入佇列是否忙碌,但徽章實際顯示「💾 bH 1」 —— io.saving 這個 i18n 鍵三個語系檔全缺(WI-207),t() 查不到時回傳鍵本身, 讓 || "儲存中" 變成死碼。判斷失效 → 提早讀取 → 假紅燈。已改為比對不會被翻譯的 💾。

2026-08-26 更新:六張卡全部修好,這一組已全綠。 每一項都經過「先紅後綠」—— 修正前該測項紅、修正後綠,同一台設備、同一支測試。 韌體 v6.0.72 經 LAN .mesb OTA 上機驗證,test:gate 35/35、test:regression 6/6。 已納入 test:gate:full,現在它真的有在守。

test:converter 是最該跑的一支。 業主買的就是「MQTT 進來能驅動輸出、 量測值能定時送出去」—— 頁面全部正常但這條鏈斷掉,設備等於沒有用。 它會自建 CV-* 前綴的素材、測完自己刪光,並以「素材必須清乾淨」作為最後一項斷言。

#閘門守著的「已知會壞的那幾類」(逐項對應真實事故)

#MQTT Converter 鏈路(npm run test:converter,5 項 + 收尾清理)

這幾項固化的是 2026-08-18 夜間的完整手動驗證。當時結論只存在於對話裡, 下次改動不會有人幫忙擋 —— 這正是「測試樣本要全面覆蓋」的意思。

#啟用/停用機制(npm run test:enable,7 項)

畫面上到處是啟用/停用的開關,先前一個都沒測。這類機制壞掉的方式特別惡劣: 「畫面顯示停用、實際還在動」(業主以為關掉了,機器卻自己跑), 或「停用之後再啟用回不來」(現場只能重開機碰運氣)。兩種都不會有錯誤訊息。

⚠ test:enable 目前不列入出貨門檻。 它已經達成目的 —— 2026-08-20 完整跑過 7/7,證實六種停用機制的語意都正確 (停用真的停、重新啟用都回得來)。但這支測試本身還不夠穩: 測項之間有順序耦合(前一項的雲端等待會影響後一項的量測)、 依賴 MQTT 環境變數(用 npx playwright -g 單獨跑會因前綴/密碼未設而失敗)。 結論可信,工具待磨。修穩之前不要拿它當出貨紅綠燈,否則會訓練人忽略紅燈。 | 收尾 | 用 afterAll 清素材(不能寫成最後一個 test,見下方) |

每一項都同時驗兩個方向:停用要真的停、重新啟用要回得來。 只驗前者的話,「停用之後就再也回不來」這種更難救的缺陷會漏掉。

收尾一定要用 afterAll,不能寫成最後一個 test。 序列模式下只要前面任何一項失敗, 後續 test 就不會執行 → 素材殘留 → 下一輪再建一份同名的 → 名稱查找抓到第一份 → 鏈路指向錯的通道 → 之後每一輪都失敗。2026-08-20 實際踩到:一次失敗滾成兩份素材, 手動清掉才恢復。 一律走「真的送 MQTT、真的看實體 DO」,不看欄位存不存得進去(那是 ST.4 的事)。

#雲端備份 / 還原閉環(npm run test:backup,4 項)

備份/還原是所有其他測試的安全網 —— 出廠測試會寫入設定、現場調參數也會出錯, 能不能救回來全靠它。它壞掉時最危險的地方是平常看不出來:設備→雲端的推送 有自己的授權路徑、照樣 HTTP 200,只有真的要「讀回來」時才發現 401。

寫這幾項時踩了兩個判準錯誤,值得記下來:

1. 不能用「快照數量增加」當判準 —— 雲端會裁切舊快照,數量可能不變;要比對最新那份有沒有換人。
2. 設定沒變更時推送不會產生新快照,那是正確行為(內容相同不重複存,實測連推 80 秒都不會多)。 所以測試要先真的改一個欄位再推,否則會把正確行為誤判成「回成功但沒發生」。

維護原則:每修一個缺陷,就在這裡加一列。 出廠測試的價值來自「它涵蓋了已知會壞的東西」,不是「它有很多項」。

#本批韌性修正:閘門測不到的那些(v6.0.41 → 6.0.65)

上面的表格是「有自動化守著」的部分。但這批交付還改了一些自動化測不到、卻直接影響 現場可靠度的行為。列在這裡不是為了完整,是因為下一個人改到這些地方時要知道當初為什麼這樣寫 —— 沒有測試會替他擋。

這張表的維護方式和上面那張不同。 上面那張是「每修一個缺陷加一列測試」; 這張是「改到這塊之前先讀這一列」。如果哪天有辦法替其中一項寫出自動化測試, 就把它搬到上面那張表去 —— 那才是真正被守住了。

#🔧 換設備 / 換現場時要改哪裡

測試分成兩類,換環境時只有第二類需要動:

#只改一個檔:web/tests/factory-env.js

const HARDWARE = {
  // RS485 上預期存在的設備。空陣列 = 該站沒有 RS485,相關測項自動略過
  rs485: [ { slaveId: 1, model: 'finder6m', name: '電流計' } ],
  // 預期的擴充模組「實際連線」數量。0 = 沒有擴充槽
  expansionModules: 1,
  hostDoWiring: '4 個 DO 接三色燈(DO1=紅 DO2=綠 DO3=藍 DO4=蜂鳴器)',
};

改完之後 ST.14 會替你把關:設定檔宣告的硬體與設備實際回報不符就直接紅燈, 不必等某個功能測莫名其妙失敗才回頭猜哪裡不一樣。

#常見情境

原則:測試碼一行都不該為了換環境而改。要改就改設定檔 —— 改測試碼會讓「這一站為什麼要特別處理」的知識散落各處,下一個人接手就看不懂。

#文件用途

本文件是正式工站操作規範，供產線測試人員逐步執行。所有步驟可由一位測試員在單一工站完成。

自動化實作（v5.9.130+，跑真實 DUT）：

🚀 一鍵測試（自動偵測 UID + 前置檢查 + 跑功能+頁面）：

bash

./scripts/run-factory-test.sh [DUT_IP] [ADMIN_TOKEN]
# 預設 192.168.72.77 / smmsadmin；輸出 12 tests PASS/FAIL

套件	涵蓋	執行
web/tests/factory-functional.spec.js	決定性韌體能力（beforeAll 自佈建 fixtures，不依賴設備現狀/RS485）：連線、MQTT 輸入、2-source AND 順序強制、signal→rule→CH_TCP publish→broker loopback（6 tests）	npm run test:factory:func
web/tests/factory-pages.spec.js	Phase 2 五頁面渲染（Overview/Config/Rules/Devices/Settings，5 tests）	npm run test:factory:pages
web/tests/factory-v6.spec.js	v6.0.x 能力回歸（純 HTTP 唯讀契約,不改 config）：Phase 0 機型身分（hasWifi/boardModel/version/mac）、Phase 6B 遠端診斷（/api/log + /api/diag + auth 401）、Phase 2E.6a MQTT 測試契約（202+輪詢）、Phase 2E.6b namespace 欄位 + TLS 出廠預設（13 tests）	npm run test:factory:v6
web/tests/factory-cleanup.spec.js	Phase 7 出貨清理（FR-H，部分 test.skip 待韌體 endpoint）	—

一次跑功能+頁面+v6 回歸：npm run test:factory（於 web/,共 24 tests）或 ./scripts/run-factory-test.sh（repo root，自動偵測 UID）。EXPECT_FW 環境變數鎖定出廠版號基線（預設 6.0.8）。

決定性原則（出廠品質基準）：functional 測試在 beforeAll 自己 idempotent 佈建 fixtures（wdprobe + ft_* 引擎元件）+ 清 retained，不依賴設備現有 config、不依賴 RS485 硬體。因此同韌體 → 同結果；唯有韌體能力改變才會讓結果變。對出廠空機也成立。fixtures 由 Phase 7 一併清除。 物理治具步驟（砝碼/SG-002/DI 開關/拔網路線）無法自動化，仍由本文件手動 ☐ 執行。 ⚠️ 跑前 watchdog 須暫停（會 reboot 干擾）。

#工站前置條件

#治具接線

#平台容量基準（硬體衍生，6.0.8 沿用）

#變體識別（機型 × 網路，二維）

工站開始前必須讀 /api/system 判定 兩個維度，並寫入結果摘要 metadata：

維度 1 — 機型（來源 = OTP boardInfo().wifi，不可靠 WiFi.status()）：

• hasWifi=false / boardModel="8310" → 8310 機型（無 WiFi 模組）：強制乙太網路;設定頁隱藏 WiFi 欄位;心跳燈 = 琥珀色（紅+綠同亮）;H6 Failover Skip;AP 模式進不了。
• hasWifi=true / boardModel="8320" → 8320 機型（有 WiFi）：可 WiFi;心跳燈 = 藍燈（LEDB）;H6 Failover 依網路變體決定。

維度 2 — 網路變體（讀 network.netType 與 /api/config interfaceMode）：

• netType="Ethernet" 且 interfaceMode=0/1 → ethernet 變體（H6 Failover Skip）
• netType="WiFi" 或 interfaceMode=2 → wifi 變體（H6 Failover 必測，僅 8320 可能）

⚠️ 8310 恆為 ethernet 變體(無 WiFi 硬體)。wifi 變體必為 8320。

工站 profile 需於啟動時設 model: 8310|8320 + variant: ethernet|wifi，寫入結果摘要 metadata。

#啟動檢查清單

• DUT 已上電，Status LED 閃爍中
• DUT 已取得 IP，工站電腦可 ping 通
• 瀏覽器可開啟 DUT Web UI（http://<DUT-IP>）
• RS485 設備已上電（Finder + YX523R 兩台）
• SG-002 信號產生器已上電
• MQTT Broker 已啟動（明文 1883）
• 機型 + 網路變體 已從 /api/system 讀取並寫入結果摘要
• 首次燒錄後首開機：Web UI 完整渲染（非裸 HTML;app.js 走 QSPI 已載入）

#Phase 0：連線檢查（FR-F、FR-A1-07）

測試記錄：

DUT UID:        ___________________
DUT MAC:        ___________________  (12-hex 對外身分)
FW Version:     6.0.8 (預期)
Board Model:    8310 | 8320
Variant:        ethernet | wifi
configCrc:      ___________________  (出廠 baseline)
測試日期:        ___________________
測試員:          ___________________

#Phase 1：初始化（FR-C1）

#Phase 2：UI 驗證

#2A. Dashboard 總覽頁（FR-A1）

#2B. Config 配置頁（FR-A2）

#2C. Rules 規則頁（FR-A3）

#2D. Devices 設備頁（FR-A4）

#2E. Settings 設定頁（FR-A5）

#Phase 3：跨頁與持久化驗證（FR-B）

#Phase 4：硬體煙霧測試（FR-C）

#H1. 初始化

#H2. Host / Expansion DO 跑馬燈（FR-C2）

測試員操作：觀察燈號與通道對應

#H3. RS485 驗證（FR-C3）

#H3-A. YX523R 光警器寫入（Slave ID=4）

透過 Dashboard setDO() 或 POST /api/modbus/manual_write（FR-I1-02）

人工確認點：測試員目視確認光警器燈色 / 爆閃模式（FR-C3-01）

#H3-B. Finder 6M.TB 讀取驗證（Slave ID=1）

#H3-B2. 同型號多台 slaveId 持久化（v6.0.2，選做）

驗 6.0.2 修正:ModbusRegister.slaveId 存進 flash,重開機後不歸零、不退回陣列位置比對 → 同型號多台不串台。需兩台同型號設備(如兩台 SF965)。單台工站可跳過並標 H3-B2: SKIPPED (單台)。

#H3-B3. 離線來源不發假 0（v6.0.7，選做）

驗 6.0.7:converter 模板引用到離線 RS485 來源時,整筆跳過發佈(不送 {"counter":0} 讓 MES 誤判計數歸零)。ConverterEngine::pushTemplate 依 _fillHadOfflineSource 跳過。需 broker 訂閱觀測。單台工站可跳過並標 H3-B3: SKIPPED。

#H3-B4. SF965 計數器原生解碼（v6.0.8，選做,需 SF965 硬體）

驗 6.0.8 新 dataType VAR_SF965_PV(=8):SF965 PV@addr4 為特規 32-bit——高 3 byte=計數值、低 byte=小數點位數(dot)→ 值 = (raw>>8)/10^dot。選 SF965 型號套預設暫存器即用此型別(不再靠 ÷256 scale 湊)。

#H3-C. TDA-08B 稱重控制器情境驗證（Slave ID=1，v5.9.111 sensor-fusion 計件器情境）

對應源碼提交 9cea4cd（v5.9.111）TDA-08B + sensor-fusion 虛擬通道 + 計數器 peak-detection。 v5.9.112+ 已移除 TDA-08B 模板，本情境必須手動建立暫存器與虛擬通道。 完整逐欄位 / 標定流程 / 排錯：docs/hardware/setup-tda-08b.md(內部文件,未公開) 治具：TDA-08B 稱重控制器 1 台、5kg 標準砝碼、感測器（壓力 / 應變片）。

❗ curl 配置時 JSON 必須 compact（無空格）：Python 用 json.dumps(obj, separators=(',', ':'))，否則 firmware parser 靜默忽略。詳見 setup-tda-08b.md §2B。

#Step 1：手動建立 RS485 設備（Slave ID=1, 9600/8N1, ABCD Big-Endian）

#Step 2：建立 Scale 虛擬通道（sensor-fusion）

#Step 3：計數器 peak-detection 規則

#Step 4：標定指令往返驗證

人工確認點：H3.16 / H3.17 / H3.21 需測試員實際操作砝碼並目視確認讀值穩定（FR-C3-01 延伸）

#Step 5：校正引導精靈 chain 驗證（v5.9.130+，選做）

驗證 MQTT-Chain 工作流校正精靈（4 步驟 + 燈號）。需先佈建 wizard（見 guide-calibration-wizard.md §5）。無 wizard 佈建則跳過並標 H3 Step5: SKIPPED。

人工確認點：H3.23/H3.25 目視燈號切換；H3.26 需實體砝碼。

#H4. 類比輸入 AI 驗證（FR-C4）

容差數值在 HW 拆工後由 web/tests/fixtures/factory-baseline.json 鎖定。

#H5. 數位輸入 DI 驗證（FR-C5）

#H6. 網路 Failover 驗證（變體 = wifi 限定，FR-C6）

Skip 條件：variant != wifi 時整個章節跳過，並在報告標 H6: SKIPPED (ethernet-only)

#H7. 跨協議多對多路由（FR-C7）

#H8. 機型感知 UI 過濾 + 心跳燈（WI-151 / WI-152，8310 / 8320）

來源 = OTP boardInfo().wifi。此章節依機型分流:8310 驗「無 WiFi + 琥珀燈」,8320 驗「有 WiFi + 藍燈」。

#Phase 5：端到端業務流（FR-G）

必須在 Phase 4 全通過後才執行。

#Phase 6：OTA + 升級迴歸（FR-D / FR-E）

#Phase 6B：遠端維運健檢（v6.0.1）

驗證 VPN-only / 現場無 USB 情境的遠端診斷能力。需 PERM_ADMIN（Bearer smmsadmin）。

⚠️ 勿以「打整頁 + 高頻並發」壓 /api/log（會觸 IWDG 重開）;/ 是 gzip,curl 用 --compressed。

#Phase 7：出貨前清理（FR-H）

由 WI-103 自動化腳本執行。

註 — 校正精靈 / wdprobe / watchdog：H3-C Step5 佈建的 wizard signals/actions/rules、以及 watchdog 用的 wdprobe signal，屬部署時佈建、非出廠基線，會被步驟 7.2 一併清除。出廠不保留；現場部署時依 guide-first-deployment.md §6 重新佈建。

#Phase 8：結果輸出與彙整（FR-F）

#總結表

自動化覆蓋：factory-functional（6）+ factory-pages（5）+ factory-v6（13,含 Phase 0 身分 4 / Phase 6B 診斷 5 / Phase 2E.6a-6b 契約 4）= 24 tests 一鍵（npm run test:factory）。其餘為需硬體/人工目視的手動項（H2~H8 燈號/砝碼/DI/AI、Phase 6 OTA、Phase 7 清理等）。

#結果摘要 metadata

DUT UID:          ___________________
DUT MAC:          ___________________ (12-hex 對外身分)
Board Model:      8310 | 8320
Variant:          ethernet | wifi
FW Version (前):  6.0.8
FW Version (後):  ___________________ (Phase 6 後)
configCrc (前):   ___________________
configCrc (後):   ___________________ (Phase 7 後)
Boot Reason:      ___________________ (Phase 6B /api/diag)
測試日期:          ___________________
測試員:            ___________________
工站位置:          ___________________
PRD v1.2 已知 bug 命中:  E-01 / E-04 / E-08 / E-09 (列舉)
擋出貨 bug:        無 | E-XX

#判定

• ☐ PASS — 全部通過 + 0 個擋出貨 bug → 可出貨
• ☐ CONDITIONAL — 全部通過 + 含 🟡 不擋 bug → 可出貨但記錄
• ☐ FAIL — 任一擋出貨 bug 或 Phase 失敗 → 退回工程修復

#失敗項目記錄

#附錄 A：API 快速參考

不存在的端點（404，腳本不可引用）：/api/devices、/api/status、/api/health、/api/version、/api/expansion、/api/tcp_io、/api/templates。

#附錄 B：操作手冊章節對照

#附錄 C：PRD v1.2 已知 UI bug 對工站的影響

已關閉 (False Positive)：E-02（TCP loading 慢顯示）、E-05（時間欄位 probe 用錯 selector）。

#文件修訂紀錄