封包遺失注入如何驗證品質標記不會留舊值

驗收目標是舊值不再冒充新資料

通訊中斷後畫面還顯示二十五度，不一定是錯；依需求可以保留最後值。真正要驗證的是它是否仍被標成即時良好，或每次畫面刷新都把確認時間改成現在。先定義值、品質與時間三者在資料停止更新時應如何變化，再做封包遺失測試。

區分網路封包遺失與應用事件遺失。TCP會透過重傳維持可靠有序的位元組流，因此丟掉某個網路封包，應用層可能只感到延遲而沒有少一筆事件。UDP或不同應用協定則有自己的處理方式，不能用同一百分比直接推定報表漏同樣比例。

本文適用於隔離測試網路與模擬資料來源，Linux netem作丟包模型的概念參考，不對正式網路下指令。RS485實體干擾、校驗錯與線路故障需要相應測試工具與工程程序，不能宣稱網路丟包已涵蓋所有串列異常。

先列品質策略：一次請求失敗如何標示、多久沒有新確認轉過期、是否保留最後值、恢復後需要什麼證據。各系統門檻不同，本文示例不是通用標準。沒有這份契約，看到畫面保持或變灰都無法判斷是否正確。

教學來源每秒確認一次資料，序號逐次增加，即使溫度維持二十五度，確認時間仍可證明採集持續。最後成功確認在零秒，接著阻斷所需回覆；示例規則是資料年齡大於三秒時標過期，等於三秒尚未超過。

畫面在一秒、二秒與三秒仍可顯示最後值，但依契約保留原確認時間；大於三秒後應顯示過期。實際前端或服務檢查有週期，驗收應訂轉態的可接受觀測延遲，不要求離散掃描在無法量測的瞬間精確變色。

若單次通訊錯誤需要立即標不良，那與三秒過期是兩個不同判斷，測試分別驗證。不能把所有錯誤都等到三秒才提示，也不能在需求只要求逾期時把每次短暫重傳都判成設備故障。狀態優先順序由契約明訂。

解除阻斷後，先讓舊歷史事件補到，再讓新的確認資料到達。舊資料不應把即時卡片年齡清零；新確認符合條件後才恢復良好。接收時間很新但來源事件很舊，是補送案例，不能與當前採集混用。

完成後應看到一條值維持二十五、品質按條件改變、確認時間不被偽造的時間線。若來源數值會變，可另用序號與值一起檢查，避免只看一條平線而無法判斷資料是否真的更新。

固定比例的獨立隨機丟包不等於每一百包必定丟掉指定數量。短測試的實際比例會波動，應保存實際送出、命中與接收的觀測數。工具設定百分之一，只代表所選模型條件，不是每次執行的保證結果。

連續一段時間收不到資料，通常比零散丟包更能驗證過期轉態。先用固定窗口的中斷建立可重現案例，再加入隨機與突發模型。Linux netem提供不同遺失模型，使用前核對工具版本、模型參數與注入方向。

TCP案例記錄重傳與應用更新間隔，而不是把網路包數當事件數。應用可能一次讀多個點，一個回應又可能跨多個封包；資料庫的唯一事件數需要另行核對。三層計數有不同分母，不能直接相減得到漏資料量。

只丟請求、只丟回覆與雙向中斷分別測。請求未到時設備可能未處理，回覆遺失時設備可能已處理；對寫入尤其重要。本文以唯讀資料品質為主要案例，任何動作命令都需先有隔離與結果確認設計。

觀察多點位的品質是否互相污染。一個站號或點位失敗，不應無條件把所有設備標不良；反過來，另一個設備持續成功，也不能替失敗點刷新確認時間。品質與時間應關聯到正確資料來源與範圍。

歷史庫保存最後值時，應連同原時間與品質保存，避免產生一連串看似每秒新量測的相同值。若系統按需求建立保持前值的時間格，另標資料來源與過期狀態，不把填補點計為實際有效樣本。

平均、警報與報表對過期資料如何處理需分別驗證。畫面變灰但報表仍把舊值當良好平均，端到端品質需求仍未完成。保留值的呈現策略不等於允許任何下游都使用它作控制或品質判定。

失敗時先查注入是否命中正確路徑，再查應用是否收到新確認、品質計時是否被刷新、快取是否把舊值包成新資料。若只有重連後短暫錯，查初始化與舊佇列；若一直不過期，查計時基準和條件是否只在收到新資料時才執行。

案例結束移除注入並確認更新週期恢復，核對遺留佇列、重試與資料品質。保存實際丟包窗口、工具設定、版本與結果，標明未測的實體層與設備限制。成功恢復不代表中斷期間品質一定正確，兩段各自判定。

練習：最後確認時間十點整，門檻為超過五秒過期。十點零四秒畫面刷新不能把確認時間改成零四秒；十點零六秒仍無新確認時應標過期。十點零七秒補到九點五十九分事件，也不能當成當前新確認。

再加入另一個正常更新的點，確認它維持良好而失敗點仍過期。這能找出程式是否用整個通訊執行緒的成功時間，錯誤代替每一點資料的確認時間。

問：TCP丟一包就一定少一筆資料嗎？答：可能重傳成功而只增加延遲，應用事件另核對。

問：保留最後值一定不對嗎？答：可以依需求保留，但時間與品質必須說明它已舊。

問：解除丟包就能立刻標良好嗎？答：需要符合契約的新有效確認，不能只看工具關閉。

問：設定百分之一就代表實際恰好百分之一嗎？答：隨機模型有波動，應保存實際觀測結果。