TestStand 檢驗與驗證

在討論檢驗與驗證的最佳實務前，先了解這些概念的差異及其在測試系統中的應用非常重要。

驗證

開發任何測試系統的第一步是了解並記錄測試需求。為定義這些需求，應從受測單元 (UUT) 的規格開始，並制定測試需求，以確保能偵測到受測單元中的任何缺陷。在開發階段，確保需求能充分定義受測單元的任何故障狀況至關重要。確保測試系統達成原始目標的過程稱為驗證。

驗證是評估系統是否實際達成其目的或意圖的過程。

驗證必須於整個測試開發過程中持續進行，且應自需求收集階段開始，因為在專案早期解決缺陷問題更容易。驗證可能包含正式的通過/未通過測試程序，或是以較主觀的方式與客戶、使用者或病患共同進行的可用性研究。驗證常涉及部分主觀需求，例如「拒絕不良品」或「易於使用的介面」。若可能，應定義更詳細的下層需求來支援這些主觀陳述，確保所有相關方對目標達成共識。

檢驗

制定詳細測試需求後，測試開發人員可設計並實施符合需求的測試系統。完成後，工程師必須確保測試系統涵蓋所有既定需求。確保測試系統正確因應特定需求的過程稱為檢驗。

檢驗是判斷測試系統是否依設計、圖紙、工作說明書或其他類似指引中所提供的規格建置的程序。

檢驗測試應在產品開發的多個里程碑階段進行。檢驗可針對整體系統或測試系統的較小元件進行。

為說明檢驗與驗證之間的差異，假設測試部門建立簡易測試設備以量測受測單元 (UUT) 的電流消耗。測試系統必須比較 UUT 電源腳的電流量測值與規定測試限制，要求 UUT 電流消耗低於 500mA。為此，測試開發人員定義需求：「UUT 電流在全功率時不超過 500mA」。開發人員設計並實現具備所需硬體的測試設備，建立測試案例，用於在供電後檢查 UUT 電流。

為執行測試系統檢驗，開發人員確認系統正確執行量測且重複性可接受，電流超過 500mA 就會產生失敗結果。若測試系統行為符合需求，即通過檢驗。

然而，製造過程存在失敗模式：逆向安裝的二極體會導致部分電路不啟動，造成極低的 150mA 電流消耗。因測試僅檢查最大限制值，故測試系統未將該問題視為失敗，可能導致不良品流出。雖然測試系統依規格正確建置，但未能達成預期目的，故未通過驗證。必須修改規格與測試系統，引入上下限量測，例如 400-500mA。

依據正確撰寫的規格、圖紙或工作説明書，系統檢驗相對容易，測試方法可能非常直接，因此瑕疵易於發現，但驗證更具挑戰，如前例所示。

影響分析

當完成測試系統的驗證與檢驗並投入使用後，您可能需要對系統進行修改或更新。原因可能為了維護、維修，或是嘗試改善與修正系統效能，例如更換故障儀器、修改演算法或設定。變更系統時，請務必了解測試系統哪些部分必須重新驗證，以確保變更不會導致出現瑕疵，此即為影響分析。 

影響分析是判斷測試系統哪些元件受到您所做變更影響的過程。

執行詳細的影響分析十分重要，因為變更可能會以不易察覺的方式導致系統無法正常運作，進而導致產品召回、生產停頓或其他業務干擾。變更也可能不影響系統正常運作但影響測試結果，導致對測試產品判斷錯誤。遺漏變更或錯誤驗證可能導致巨額成本。部分產業中，不良品流出可能招致產品召回。FDA 有權採取監管行動。 

為降低系統變更帶來的影響，務必以模組化設計測試系統，使元件變更不影響其他元件。實現此目標需確保元件之間完全獨立，並採用獨立的驗證程序。例如，您可採用硬體抽象層 (HAL)，以提供標準函式集介接硬體。HAL 所定義的函式可獨立於其他測試系統元件進行驗證。若進行硬體變更，影響將限於 HAL 層，因為您可於變更後檢驗 HAL 函式行為是否一致。

驗證與檢驗產業標準

多數產業已明確定義 V&V 之管治原則，並由良好製造規範 (GMP) 等專業實務或 ISO-9000、FDA 的 21 CFR 或是 IEEE 標準等法規所界定和説明。各 V&V 系統用語略有差異，但皆說明兩程序的共通需求。具體需求通常未明確定義。本文件探討自動化測試系統的 V&V 流程。

FDA 的 21 CFR 中關於醫療器材之驗證需求較為模糊，僅以字句規定必須對醫療器材執行驗證以符合使用者需求與原定用途，因此品質系統管理者必須定義需求並監督驗證測試。對測試系統而言，定義驗證測試的一種簡單方法，就是追蹤已知失敗模式，並提供良品與不良品樣本，確保系統能偵測已知瑕疵。另一方法可能是使用可靠的手動測試程序，或以其他自動化系統驗證新測試系統結果。 

部分驗證案例必須極為徹底，如航空、製藥及醫療器材產業，因其驗證流程涉及安全、品質或成本的極端情境。完整系統驗證可能需數週或數月來定義與執行。例如，若測試系統使用 16x32 設定的切換矩陣，測試工程師可能利用連續性測試機測試所有可能的連線組合，確保不會出現受限制的連線。另一範例可能是驗證通訊系統，必須測試並驗證其中所有可能的指令與指令序列。儘管這些驗證程序看似嚴苛，但在任何狀況下皆必須確保無損壞、傷害或錯誤結果發生。

V&V 程序以明確定義的規格為核心。驗證亦可能受到客觀問題影響，如市場或終端用戶需求定義不明。任何測試系統最重要的第一步是研究並記錄完善的工作規格與 V&V 需求。若規格不具體、存有解讀空間或歧義，確保測試系統完整將相當困難。若稽核員或觀察員發現設定未記錄或錯誤執行，可導致測試中止。審慎實作撰寫完善的規格，有助於確保 V&V 程序順利無礙。

檢驗作業需一份或多份設計文件或圖紙，規範系統必須完成的事項。 文件與圖紙可能涵蓋元件、組件或整套系統。檢驗的規格與測試方法必須為詳盡文件，具備建立正確測試系統所需資訊。

務必詳實紀錄所有規格變更，不論由客戶、工程師設計，或經學習及探索所產生。應採用變更訂單程序，記錄變更與原因，並使變更正式生效。僅當指令、設定與測試限制符合正確文件時，檢驗才算通過。 

設計驗證測試常帶有主觀色彩，看似藝術多於科學，雖然智慧與經驗是驗證設計的重要工具，但收集需求同樣具啟示性與效用。技巧包括檢視其他測試設備或產品的歷史效能，訪談操作者及其主管，並研究歷史量測資料。一家公司常委外給測試系統整合商，會詳細回顧每個專案以尋求改進方法，並將這些想法列入下個專案的檢查清單。

TestStand 以模組化架構為建構基礎，具多個獨立元件，包括 TestStand 引擎、流程模型、測試程式碼與使用者介面。此架構有利於 V&V，因各元件更易於獨立分析。此外，現有測試系統的變更所需重新驗證較少，因爲影響常限於單一元件。

TestStand 的模組化架構允許各元件獨立檢驗與驗證，減少變更對整體測試系統的影響。

設計測試系統時，務必考慮檢驗與驗證並以有利此兩項作業的架構設計系統。下列章節將介紹以 V&V 為核心設計測試系統元件的最佳實務。

設計序列檔案

開發測試序列時，請秉持以下目標：

• 利用子序列將功能劃分為邏輯功能區塊以組成元件。
• 減少步驟間的互動，降低個別步驟變更對測試系統的影響。

聚焦此等目標有助於追蹤測試程式碼覆蓋的需求，並減少變更個別步驟造成的影響。  

使用個別步驟與步驟設定

定義步驟條件時，須判斷條件是否會應用於多個步驟。使用 If/Else 或 Case 步驟實現邏輯，於 TestStand 環境中更清晰可見，且具擴充性，能依條件執行多個步驟及多個選項。然而，這會導致測試步驟與流程控制間產生關聯。對於必定只適用於單步驟的邏輯，使用預先條件可將邏輯與步驟包含於單一元件內。
執行測試程式碼切換時，也應採用類似方法。針對僅適用單一測試的路由，使用步驟的切換設定，可將切換功能與測試程式碼組合成元件。若切換影響多個步驟，使用切換步驟能讓序列中的切換更清楚可見，並讓序列更具自我記錄能力。

使用子序列進行模組化

為結合內建步驟設定元件化與獨立步驟擴充性，可建立子序列來封裝相關步驟組合。將此類子序列組合置於獨立序列檔，可有效建立序列儅，也就是函式庫，能於多個測試應用間獨立驗證並共享。
此外，測試序列幾乎整體由 Sequence Call 步驟構成，每個步驟實作測試的邏輯分組。子序列的組織方式應對應測試規格，高階需求（如「系統應測試裝置音訊功能」）應對應測試中的某個序列，較低階支援需求（如「最大音量不得超過 80 dB」）則對應序列內的步驟。

減少多個步驟之間的相依性

若步驟需使用前一個步驟所得資料，會形成步驟間的相依性。避免使用 PreviousStep 屬性直接存取其他步驟資料，改用本地變數儲存第一步驟資料，然後在後續步驟存取該變數。

還應確保每個步驟在測試執行前獨立設定或檢驗必要條件。例如，若音量測試步驟包含在低、中、高音量下的音量測試，後續音質測試必須在中音量下執行，則應確保先將音量設定為中等，再執行測試。此作法確保兩項測試獨立：變更音量測試不會影響音質測試。

記錄測試序列

清楚記錄序列檔案是確保規格所有需求皆被充分涵蓋的重要因素。但應避免於說明文件中重複使用資訊，如限制值或測試參數。 

可利用步驟名稱與說明來記錄步驟的目的。步驟名稱應描述該步驟執行的內容與原因，但不應包含步驟中定義的參數值。例如，步驟名稱不宜命名為「Wait」，應命名為「Wait for system to boot」。若名稱需補充資訊，請利用步驟的「說明」屬性加以註明。

您也可利用 TestStand 與 NI Requirements Gateway 整合，有效追蹤需求於實際測試程式碼的涵蓋情形。NI Requirements Gateway 可迅速顯示需求涵蓋狀況，並能導向涵蓋該需求的步驟，加速檢驗流程。

NI Requirements Gateway 讓您在需求文件、測試序列與測試報告間建立連結，確保所有需求皆被涵蓋。

您可使用適用於步驟、序列及序列檔的「Requirements」(需求) 欄位，以提供涵蓋的需求資訊。這些欄位能搭配 NI Requirements Gateway 使用，在需求文件與測試程式碼之間建立對應，快速查看需求涵蓋範圍。 

利用需求欄位將步驟、序列或序列檔對應至規格文件中的特定需求。

欲了解更多關於使用 NI Requirements Gateway 搭配 TestStand 追蹤需求的資訊，請參閱結合 NI Requirements Gateway 與 NI TestStand 線上教學。

開發獨立程式碼模組

TestStand 步驟呼叫程式碼模組與儀器及自動化硬體通訊。程式碼模組可透過多種語言實作，包括 LabVIEW、C++ 或 C#。TestStand 提供步驟與程式碼模組的自然邊界，編寫可獨立於 TestStand 序列測試並驗證的程式碼模組為佳。 
為確保程式碼模組能在測試序列外獨立測試，應避免使用 SequenceContext 或其他 TestStand 參考直接存取資料，而是以參數將資料傳遞至程式碼模組。若須用到 SequenceContext，如實作終止監控，則設計程式碼模組，使其能於無 TestStand 專屬程式碼環境下運行。在 LabVIEW 程式碼模組中，可用「非參考」函式檢查 SequenceContext 是否有效，然後再使用。

透過可獨立執行的程式碼模組，可設計測試設備，對程式碼模組進行迴圈，傳遞所有輸入參數排列組合。測試設備將結果與已知正確結果比對，以驗證程式碼模組行為符合預期。

使用外掛程式變更流程模型

TestStand 流程模型可處理非專屬於受測單元的測試功能，包括 UUT 追蹤、報告生成、資料庫記錄與批次或平行測試。TestStand 附帶的流程模型相當複雜，變更此類模型需要大量驗證工作。 

流程模型採用外掛架構，實作預設的報告產生與資料庫記錄功能。您可利用此架構擴充現有流程模型的功能，而不須變更流程模型序列檔本身。為此，您需建立客製化外掛程式，並於獨立的外掛程式序列檔中實作。您可獨立驗證此外掛程式的行為。

流程模型外掛程式是流程模型檔案的獨立元件，可分別進行驗證。

若需於流程模型中直接變更功能，例如變更收集 UUT 序號的方式，建議停用流程模型中執行現有功能的步驟，再為新功能建立獨立外掛程式。使用此方式後，您未來對客製行爲的變更僅限於外掛程式，便於重新驗證。 

有關流程模型與外掛程式客製化詳情，請參閱 NI TestStand 流程模型開發與自訂最佳實務文件。

管理測試設定與配置

開發測試系統時，務必確保所有測試站的所有 TestStand 設定皆相同，且任何變更皆經妥善驗證。然而，許多 TestStand 元件具有獨立設定，因此很難確保不會有任何變更。除了 TestStand 設定外，還須確保各測試系統間的儀器設定一致。儀器設定可包括 NI Measurement & Automation Explorer (MAX) 中 NI-DAQmx 設定，或裝置的 GPIB 與 COM 設定。此類設定眾多，且驗證測試設計困難。

確保設定正確的方法之一，是在測試序列中以程式設計方式設定，然後查詢每個設定以確保儀器或程式接受設定。若無法查詢設定，請尋找設定存放位置，從文字、INI 或 XML 檔案讀取。系統可檢驗及記錄 TestStand 以外項目的狀態，並加以控制。

使用原始碼控制工具管理檔案

另一種管理設定的方法是嚴格控制包含設定的檔案。儲存所有 TestStand 設定的配置檔位於 <TestStand Application Data>\Cfg 目錄。有關其他設定，請參閱產品專用說明文件以了解設定檔位置的資訊。
監控、控制與儲存測試系統檔案的業界標準方法為 Subversion、Perforce 及 Microsoft Visual Source Safe 等原始碼控制 (SCC) 程式。其中多數程式符合 Microsoft SCC 介面，並可於 TestStand 或 LabVIEW 中使用。在某些情況下，您須暫時擁有檔案並記錄變更，才能進行修改並保存。這些程式通常能告知您檔案變更情況及分析新舊檔差異，使檢驗更為簡便。

亦可使用檔案檢查碼，確保設定檔自驗證狀態後未變更。採用此法可新增步驟，用以比對檢查碼與您為已驗證檔案計算的檢查碼，若二者不相符則產生測試失敗。   

除測試系統外，務必確保支援測試的軟硬體均處於已知且經過驗證的狀態。本節說明維護系統狀態的技巧及必要時套用變更的辦法。

管理硬體設定

必須針對整個系統與個別測試，正確選擇、安裝、設定儀器及進行程式設計。例如，多功能數位電錶 (DMM) 或示波器要進行正確的通訊與訊號擷取，需設定多個選項，這些設定必須在測試系統完成時以及未來硬體變更時進行檢驗與驗證。

建立硬體抽象層 (HAL) 管理硬體互動，有助於減少測試系統硬體變更時需要的重新驗證工作。與在測試序列中使用裝置專屬程式碼模組不同，HAL 能讓量測種類與儀器專用驅動程式脫離測試序列。測試程序通常根據儀器類型（如電源、多功能數位電錶 [DMM]、類比輸出與繼電器）定義，不限定特定儀器，採用抽象層讓測試序列更能適應新的儀器與需求。若有 HAL，就可以透過在一組測試案例中確認 HAL 函式對新硬體產生的輸出與先前一致，來驗證新硬體，無需完整測試整體系統。關於使用 HAL 的更詳細資訊，請參閱建置測試系統的基本原理：硬體與量測抽象層。

於執行階段驗證硬體也是一個好做法。執行階段讀取並儲存設定或其他因素，使您能確信需與軟體一同驗證的項目已配置且運作正常。例如，TestStand 步驟可查詢儀器校準日期以確保校準最新，並能檢驗連接至 COM 連接埠儀器的型號與序號，以確定儀器未被更換。設計測試序列及購買儀器時考慮此類因素，有助簡化 V&V 程序。

若預計硬體必須變更，則必須將此變更納入 V&V 程序考量。儀器故障且以相同廠牌與型號替換時，須思考如何檢驗其是否正常運作，並設計測試以確保變更成功。利用可互換虛擬儀器 (IVI) 驅動程式與介面設定儀器，可協助簡化同廠牌或型號間，或異廠牌與型號間的儀器切換。

管理軟體設定

維護測試系統時，須考慮升級 LabVIEW、TestStand 或任何其他程式，以利妥善利用這些新功能。這類軟體升級一律會觸發重新驗證與重新檢驗。應將可能升級視為投資報酬率 (ROI) 之考量。例如，可能想於開發階段升級以取得更流暢的開發介面，但系統部署後則不考慮升級。不過，如近期 TestStand 升級所示，執行速度提升可縮短測試時間、提高產能與營收。不論何種情況，重新驗證成本為決定因素，但該成本亦可帶來正 ROI，因而值得投入費用與心力。通常應同時完成多項軟體升級，以減少需驗證軟體的次數。

為保持測試系統軟體一致，建議先透過經過驗證的系統建立基礎映像檔，設定新測試站時使用此映像檔。不過，即使使用基礎映像檔，仍必須確保不進行軟體更新。針對 NI 軟體，須確保 NI Update Service 設定為從不自動安裝更新。大部分電腦預設會自動進行 Microsoft 更新。其他廠商如 Sun、Apple 與 Adobe 也使用網路式自動更新。凡受 V&V 程序管控的系統皆須停用任何自動變更與升級功能。自動更新所做的變更無法預測，可能對運作與設定造成未知影響。 

您的 IT 部門可能有一般政策管控公司電腦，包括使用病毒掃描軟體、設定熒幕保護程式等安全策略，並視需要安裝修補程式與更新。製造部門必須與 IT 部門合作以協助管理 TestStand 系統，確保這些系統保持原狀而不被改動。您必須決定哪些項目會具體影響電腦，但您的需求可能與 IT 政策相異，如移除病毒掃描軟體、關閉螢幕保護程式以及免除公司範圍的升級或修補程式。

按一下即可檢視 TestStand 進階架構系列的其他文件，文件涵蓋進階 NI TestStand 開發人員感興趣的各種主題。