在醫療軟體開發中，測試是開發與釋出前的重要環節之一。我們透過測試，確認產出的功能與行為是否符合需求，並發現可能影響品質與安全的問題。因此，如何設計測試、判讀結果，是開發時需要認真考慮的事。
如果軟體包含 AI/ML 模型，測試也需要考慮模型的特性。這篇會聚焦兩項內容：
接下來的篇幅，我們將介紹兩者在測試方法與結果判讀上的差異，以及需要注意的地方。
核心問題：我們是否正確地實作了規格？程式邏輯有沒有寫錯？
在軟體開發中，有許多項目可以加入測試：業務邏輯、邊界條件、防呆...，一般可以根據需求來設計測試。譬如，一個輸入血壓的頁面，我們一般會測試輸入框的參數與結果，參數正常，可正常儲存、參數不正確，不可正常儲存，會出現錯誤對話框、參數若輸入文字，不可儲存，出現錯誤對話框... ，編寫測試程式碼時，我們會針對需求建立不同的測試來滿足需求。除了原本需求的 Happy Path 以外，還需要包含邊界條件。藉由使用不同的測試案例來清楚描述需求，將需求的輪廓更清晰的呈現，同時也可以幫助發現改 A 壞 B 的問題。
軟體邏輯測試強調「與需求的追溯性」。每一個測試案例都應能對應到特定的軟體需求或風險控制措施，確保測試有明確依據，並能證明所有需求皆已被驗證。這種追溯關係也有助於在需求變更時，快速評估影響範圍。
測試軟體邏輯時，一般會包括以下測試方式：
測試策略與作法：
與等等介紹的模型測試，軟體邏輯的測試，相對來說是比較單純的，使用二元判定（Pass or Fail），測試前先訂好預期結果與判準，再判定通過或失敗。
核心問題：這個模型是否足以代表真實世界（或臨床現實）？在預期使用情境下，預測結果是否可信？
在現今軟體應用中，越來越多軟體都包含 AI/ML 模型。與軟體邏輯測試的最大差異在於：AI/ML 模型是透過資料訓練而成，其表現會受到資料品質、訓練方法與實際輸入條件的影響。因此，評估模型時必須使用獨立於訓練過程的測試集，觀察它在未見過的資料上的表現，以及在哪些情況下容易判錯。
測試策略與作法：
• 資料集嚴格隔離（Dataset Isolation）：依據 TFDA《人工智慧/機器學習技術之醫療器材軟體查驗登記技術指引》，必須嚴格拆分訓練用資料集（Training Dataset）與測試用資料集（Test Dataset）。測試集絕對不能參與訓練或超參數調校。
• 防範資料洩漏（Data Leakage）：醫療資料最常踩的坑是「把同一個病人的多次量測紀錄，同時分到訓練集與測試集」，導致模型對該病人的特徵「背答案」，測試分數虛高。
• 臨床效能指標評估：若評估的是有參考標籤的二元分類模型，可使用靈敏度、特異度、正確率及偽陽性／偽陰性率；再依模型輸出與評估目的，決定是否使用 ROC-AUC。
判定標準：
模型評估是依據事先訂定的效能指標與接受準則來判斷，而非要求 100% 單點無誤。當出現偽陽性或偽陰性時，需記錄並分析原因，確認是否涉及實作問題，以及誤判可能對使用者造成什麼影響。
在醫療軟體開發中，測試協助確認功能與行為是否符合需求，也能在修改程式後發現回歸問題。軟體邏輯測試依預期結果判定通過或失敗；AI/ML模型則還需要獨立測試集，評估整體表現與誤判情況。資料洩漏是測試資訊進入訓練或調參，造成評估偏差。遇到偽陽性或偽陰性時，應分析原因與可能影響，並交代測試資料、版本及適用範圍，保留完整結果紀錄。
Ref:
iThome鐵人賽
看影片追技術