從實際差異決定要測什麼
線上修改完成只表示某次寫入操作完成，不能代替功能回歸。先把修改內容轉成輸入、條件與預期輸出，再追它影響的資料和呼叫者，才能決定要測哪些情境。本篇以Q06UDVCPU與GX Works2為背景，教你建立可審查的測試表，不直接執行現場變更。
三菱QnUCPU第3.12節與GX Works2第15.9節分別說明線上修改型態及限制。一般梯形圖、檔案修改、SFC及上升下降處理可能有不同注意事項。先依實際程式型態核對章節，不能因別案曾成功，就認定本案可以在相同狀態下修改。
保存核准前版、新版、差異清單、CPU身份與工具版本。測試計畫應在寫入前先定義；若已發生修改，先保存現況和可取得的操作記錄，再補查缺失基線。沒有前版就不能宣稱已證明未改區完全維持原狀。
將驗收拆成內容一致、功能結果和執行條件三層。Verify with PLC回答選定資料是否相符，輸入輸出案例回答邏輯是否符合需求，掃描與現場觀察回答代表性條件下是否能工作。任一層通過都不能自動替另外兩層填通過。
本篇的測試數字是非安全報警範例，機台動作仍由原設計處理。任何需寫入、模擬輸入或操動設備的驗證，必須在已核准且風險受控的環境安排。
把一個門檻修改展開成邊界案例
假設原需求是有效溫度大於25.0度時產生一個報警需求位，新需求改為大於30.0度。先確認比較是嚴格大於，不是大於等於；再確認溫度已是工程值，而不是未縮放整數。若實際資料253代表25.3，就需要核對既有倍率，不能直接將原始數字拿來比較30。
定義本例無遲滯、無延時且報警啟用為真，輸入資料有效。離線表應列29.9度需求為0、30.0度為0、30.1度為1。這三點分別驗證低於、等於與高於門檻；只測20和40容易漏掉等號寫錯，正好在30.0時才發現問題。
再加入25.1度，原版會要求報警而新版不會，這是本次允許改變的行為。將預期差異寫進測試表，避免測試者看到報警變少就誤判失敗，或看到任何差異都說是新需求。允許差異只限已核准條件，不擴大到其他報警。
啟用為假時，依本例規格報警需求位應為0；資料無效時，溫度高限需求不採用舊有效值，另外標資料無效。這是本文示例規格，實際專案可能有不同策略，必須先寫清楚。需求位、警報歷史、確認狀態和實際設備互鎖不可混成同一欄。
若現場原程式另有保持、延時或遲滯，這張簡表就不完整。補上初始狀態、前一筆值、時間經過及復歸條件，才可推導結果。不能刪掉原有狀態處理，讓程式看起來符合本篇無狀態範例。
沿著依賴找出回歸範圍
從修改的比較條件向前追溫度來源、縮放與資料有效性，向後追報警需求位的所有使用者。它可能被HMI顯示、報表、通知或流程許可引用。每個使用者列出是否受影響及理由，不要只因目前看得見一個燈，就把測試範圍限制在那個燈。
若比較邏輯封裝在共用FB，盤點所有實例和呼叫程式。原以為只改一台槽的門檻，實際可能改到同一FB其他設備。測試表應至少涵蓋修改實例與一個預期不受影響的代表實例，再按共享資料與配置差異決定是否需逐一測試。
有些資料以索引或區塊方式被存取，普通裝置字串搜尋未必展開全部影響。先做交叉參照與範圍分析，再選回歸案例。外部HMI與通訊工程不會全部出現在PLC搜尋結果，需要依實際資料契約補查。
對未變更功能，選擇與修改點共用狀態、輸入或資料區的案例，不必機械式重跑毫無關係的所有功能。例如同一溫度另有低限報警，應確認它仍按原門檻工作；與該資料完全無依賴的獨立照明，則依設備驗收規範決定是否納入。
完成後應能從每個測試項目追到一個差異、依賴或已知風險。若某項沒有預期結果，就還不是可執行的測試；若某個受影響輸出沒有任何測試覆蓋，就要補測或明示待驗，不以總共測了很多項掩蓋缺口。
區分內容比對與現場結果
先在副本完成必要的轉換或編譯，保存實際結果；再於核准流程中對指定CPU與資料範圍作內容比對。只有語法可接受，也不代表倍率、位址或狀態邏輯正確。
功能測試記錄輸入來源、初始狀態、操作、預期與實際結果，並附時間窗口。數字直接填在離線表是算例，模擬器跑出的結果是模擬證據，現場量測是硬體證據。三者分開標示，不能用對應結果欄填入實機實際欄。
線上修改期間若有邊緣指令、指標或SFC狀態，需另按對應手冊核對切換行為。不能推定修改後所有內部狀態都自動初始化，也不能推定全部保留；測試先列出哪些狀態需要保持、重建或重新確認，再查平台與設計是否符合。
若觀察到掃描尖峰或輸出暫態，保存目前值、最大值的累計範圍及事件時間。測試本身增加的監看負載也要記錄。比較前後需同類工作條件，不能用閒置狀態新版數字去對滿載前版，然後宣稱性能改善。
回復方案也要列限制。還原舊程式不會自動撤銷已送出的通訊命令、已寫入外部系統的資料或機台已完成的動作。回復前先核對當前狀態與不可逆影響，不能把重新下載前版當成回到過去同一瞬間。
失敗排查與驗收FAQ
某項失敗時先固定證據，查輸入是否符合案例、版本和比對範圍是否正確，再追狀態及依賴。修正後重跑受影響的案例及必要回歸，不為了讓總表變綠而改預期值。交付明確列通過、失敗、未執行及不適用，並附各自理由。
問：門檻大於30時，30.0要報警嗎？答：本例嚴格大於且無其他狀態條件，所以不要求報警；30.1才要求。
問：Verify一致就代表功能正確嗎？答：不代表，仍需按輸入與狀態測預期行為，比對只涵蓋選定資料內容。
問：只改一行就只測一行嗎？答：沿資料和共用FB依賴決定範圍，可能影響多個實例及外部使用者。
問：回復舊版就能撤銷所有影響嗎？答：不能，外部命令、物料和機械動作需另行核對，回復方案必須處理當前真實狀態。
參考：三菱GX Works2 Common 第15.2節及第15.9節 比對與線上修改
參考：三菱QnUCPU手冊 第3.12節 線上修改與注意事項 印刷頁169起