TestStand 程式碼模組開發最佳實務

開始開發測試系統前，請從測試系統下列層面，考慮為通用方式定義：

• 程式碼模組精細度：為各模組功能範圍定義。
• 為測試程式碼目錄架構定義：如目錄架構的定義完善，即可輕鬆地與其他開發人員共用程式碼，並將程式碼佈署至測試系統。

程式碼模組精細度

設計測試系統時，必須針對程式碼模組定義具一致性的精細度層級。 精細度 (Granularity) 是指測試系統中每個程式碼模組的功能範圍。 低精細度測試序列僅呼叫少量的程式碼模組，每一個模組都會執行更多功能，而高精細度測試序列則會呼叫多個程式碼模組，且每一個模組的範圍都較小。

您應為這些極端情況取得平衡，因為每個極端都有自己的優勢。 

使用不同層級的精細度執行簡單測試

如要使精細度在測試系統中保持一致，則需建立程式碼模組開發標準集，例如：

• 在不同的程式碼模組中執行硬體初始化與關閉作業，即可由 TestStand 來管理硬體工作階段的生命週期。
• 為每個需求項目建立單一測試步驟，才可確認測試所需的精細度。 如此一來即可輕鬆確保滿足所有需求。 此外，NI Requirements Gateway 可搭配 TestStand 使用，以便在測試步驟與需求文件之間建立連結。 如需更多資訊，請參閱偶合 NI Requirements Gateway 與 TestStand 教學。
• 使用所需的測試結果結構，以便決定個別步驟的範圍。 由於每個步驟都會建立結果輸入，因此只要建立測試步驟與所需結果輸入的一對一對應，即可輕鬆組織測試結果，且報表或資料庫紀錄僅需極少變更。

定義序列檔案與程式碼模組的目錄架構

在測試步驟中指定程式碼模組路徑時，可選擇使用絕對或相對路徑。建議避免使用絕對路徑的原因如下：

• 若將序列檔案與其相依性移至磁碟，則路徑將不再有效。
• 若將序列檔案佈署至目標機器，則路徑將無效，除非檔案已安裝於相同位置。

指定相對路徑時，TestStand 會使用搜尋目錄清單來解析路徑。 這些搜尋目錄通常包含目前的序列檔案目錄、TestStand 特定目錄與系統目錄。

開始開發前，請務必先定義測試序列與程式碼模組的檔案架構。 為序列檔案與程式碼模組定義儲存策略時，可參考下列指南。

• 針對單一序列檔案所使用的程式碼模組，請將程式碼模組檔案儲存在與序列檔案相對應的子目錄中。 如此可確保序列檔案在移至系統，或複製至其他系統時，可隨時找到程式碼模組。
• 針對多個相關序列檔案共用的程式碼模組，若將相關序列檔案儲存在相同目錄中，則可使用與單一序列檔案相同的方式。 請考慮建立工作空間，以容納所有相關的序列檔案與程式碼模組。
• 針對由多個不相關序列檔案所共用的程式碼模組，請考慮建立特定目錄，以包含所有共用的程式碼模組，並建立新的搜尋目錄，以便指向此位置。 如此可確保，系統中的任何序列檔案均可透過此搜尋目錄的相對路徑，來找到所需檔案。 佈署程式碼模組時，可以佈署搜尋目錄設定檔案，其位於 <TestStand 應用資料>\Cfg\SearchDirectories.cfg 中。 若使用此方式，則勿在目錄中移動程式碼模組檔案，以免破壞呼叫序列檔案中的指定路徑。

定義程式碼模組位於序列檔案子目錄中的目錄架構

使用 TestStand Deployment Utility 來佈署測試程式碼時，可選擇序列檔案與相關程式碼模組的特定目的地。 若在序列檔案與程式碼模組的目的地目錄之間存在相對路徑，則 TestStand Deployment Utility 將更新序列檔案中的路徑，以指向已更新的位置。 在多數情況下，最好將佈署的目錄架構與開發系統的目錄架構相匹配，以確保佈署與開發機器上的程式碼儘可能相似。

為測試系統定義程式碼模組範圍時，請務必定義將在程式碼模組與序列檔案中執行功能的策略。下列部分可協助您決定最合適的位置，以執行常見功能：

• 根據限制來評估測試量測
• 定義激發值
• 回報並記錄測試結果與錯誤
• 迴圈作業
• 執行切換作業
• 執行計算並操作資料

評估限制與測試結果

在理想情況下，程式碼模組應包含與取得測試量測結果有直接相關的功能，且測試序列應處理原始測試結果。此方式具有下列優點：

• 序列檔案中的測試限制更容易管理，因為可以使用屬性載入器 (Property loader) 等工具，在單一集中位置為多個步驟管理限制。
• 在序列中定義的測試限制會被自動納入測試結果，如報表或資料庫。
• 不需變更程式碼模組即可更新測試限制，且僅需修改測試序列即可減少檢驗作業。

針對較簡單的量測，程式碼模組可將原始量測值回傳至序列以進行處理。舉例來說，若測試步驟是量測受測單位 (UUT) 特定針腳的電壓，則程式碼模組應回傳量測值，而非直接於程式碼模組中執行檢查。 您可透過數字限制測試步驟來處理此數值，以確認序列檔案中的測試結果。

評估測試步驟中的限制，可簡化程式碼模組，並改善結果記錄

然而，由於某些測試的複雜性，並非總能在序列檔案中處理原始測試結果。 針對更複雜的量測，結果資料可能必須進行額外處理。 複雜資料可處理為單一字串或數字結果，接著可使用字串或數字比較，在 TestStand 中進行評估。 舉例來說，頻率掃瞄測試的結果相當複雜，無法直接評估，但可將資料處理為代表最小值的單一數字。 在此情況下，程式碼模組應評估已處理的結果，並以獨立參數回傳頻率資料以便記錄，如下方行動裝置測試範例所示：

針對更複雜的資料，可於程式碼模組中處理資料，以產生數字或字串結果，並使用參數來傳遞原始資料進行記錄

如果原始資料非常龐大，則將資料傳遞至 TestStand 可能會對效能造成重大影響。 在此情況下，可考慮將資料直接記錄至 TDMS 檔案，並從測試報告連結至檔案。 如此即可直接參考報表中的資料，不需將資料傳送至 TestStand。 如需進一步了解此方式，請參閱在報表中包含超連結 - TDMS 檔案。

如果無法使用測試步驟中的評估類型來確認測試結果，則可考慮建立新的步驟類型，並提供額外功能，以處理所需的測試類型。 如需深入了解如何建立客製化步驟類型，請參閱此系列文章的客製化步驟類型開發最佳實務。

定義測試激發

就許多測試而言，UUT 或測試環境必須處於特定狀態，才能執行測試。 舉例來說，進行溫度量測時可能需要激發電壓，或是必須將加熱室設定為特定溫度。 針對這些類型的模組，可使用參數來傳遞輸入值，例如激發電壓或所需的溫度。 如此一來，即可於測試程式碼模組中回傳原始資料，而非直接於程式碼中回傳處理限制（如前一節所述）。

記錄測試結果

TestStand 提供內建功能，可使用測試步驟的結果來產生報表，並記錄資料庫。因此，應避免直接於程式碼模組中執行任何類型的資料記錄作業。 反之，則應確保所要記錄的任何資料均已作為參數傳遞出去，並使用 TestStand 來記錄資料。 某些資料會自動記錄，例如測試結果、限制與錯誤資訊。 若要記錄其他資料，則可透過額外的結果功能，來指定額外參數並納入報表。

若要進一步了解如何將結果新增至測試報表，請參閱將客製化資料加至報表範例（列於 TestStand 中）。

若有特定的記錄需求，可考慮修改或建立結果處理外掛程式。如此即可使用內建 TestStand 結果集合來收集結果，並同時確認處理與呈現結果的方式。請參閱 TestStand 流程模型開發與客製化最佳實務文件中的「建立外掛程式」部分，以取得更多資訊

迴圈作業

由於每種方式都有其優缺點，因此難以判斷最佳的迴圈實務。請參考下列指南，以確認最適合您應用的策略：

於程式碼模組內進行內部迴圈

• 提升效能，尤其是快速迴圈時。 由於每個程式碼模組呼叫都可能產生數個毫秒的系統負載 (Overhead)，因此如使用外部迴圈執行數百或數千次循環，可能會影響測試速度。
• 可進行更複雜的迴圈動作。 

於序列檔案中進行外部迴圈

• 不需修改程式碼模組，即可直接於序列檔案中檢視並修改迴圈設定。
• 輕鬆存取序列檔案中的迴圈索引。 此功能有助於判斷切換器路由，或其他會根據目前循環而改變的行為。
• 迴圈的每次循環都會分別記錄，並於報表或資料庫中顯示每次循環的結果。

執行切換作業

許多測試系統均採用切換，以便使用單一硬體來測試多個站台。 切換器可透過預先定義的路由，以程式設計的方式，來控制將哪些受測單元 (UUT) 的針腳連接至特定硬體。 

可透過下列方式於 TestStand 程式碼模組中執行切換功能：

• 使用步驟的內建切換器屬性（需要 NI Switch Executive）
• 使用 TestStand IVI 切換步驟（僅限 32 位元 TestStand）
• 直接呼叫切換器驅動程式功能

使用 NI Switch 硬體時可透過 NI Switch Executive 快速定義路由。如有 NI Switch Executive 的使用權限，則內建的切換步驟設定通常是最佳方式，且具有下列優點：

• 在步驟中定義切換器設定，可將切換功能與測試程式碼分離，進而提高重複使用率，並降低程式碼模組的複雜性。
• 切換設定中有許多欄位均由表達式指定，以便使用 RunState.LoopIndex 屬性或另一個變數，為循環步驟的路由或路由群組名稱建立索引。
• 針對平行測試，可使用測試插槽索引 (RunState.TestSockets.MyIndex) 做為路由字串的一部分，以便針對每個測試插槽來使用不同的切換器路由。
• 可將連線生命週期與步驟、序列、執行緒或執行作業相關聯。

使用 NI Switch Executive 直接從 TestStand 步驟設定中指定路由，包含支援 TestStand 表達式，以便使用電流迴圈索引或其他屬性以動態方式來確認路由

執行計算並操作資料

為避免針對較簡單的工作項目維護程式碼模組，可使用 TestStand 中的表達式語言，來執行基本計算與單一維度陣列操作。由於程式設計語言可提供更強大的功能，更適合這些作業，因此必須於程式碼模組中執行更多的進階程式設計需求。 舉例來說，透過 LabVIEW 原生建立陣列 (Build array) 功能串聯多維陣列要比表達式語言輕鬆得多。

在某些情況下，可使用 .NET Framework 所提供的原生類別，以避免建立過於複雜的表達式。 舉例來說，不需建立程式碼模組，即可使用 System.IO.Path 類別，快速執行路徑操作。

不需程式碼模組，即可透過 .NET 步驟來使用 .NET Framework 方法

執行程式碼模組時，有許多設計決策會影響所建立的程式碼模組。 本節為下列概念提供指南：

• 將資料從 TestStand 傳送至程式碼模組
• 處理程式碼模組中的序列終端
• 將程式碼模組錯誤回報至 TestStand
• 管理程式碼模組的執行速度與記憶體使用率

將資料從 TestStand 傳送至程式碼模組

在程式碼模組中存取 TestStand 資料的方法有 2 種：

• 透過程式碼模組參數傳遞資料
• 使用 TestStand API 直接存取程式碼模組中的資料

在多數情況下，最好使用參數傳遞資料，而非使用 TestStand API 直接存取資料，原因如下：

• 不易出錯：由於在 TestStand 步驟類型設定中定義參數值，而非直接在程式碼模組中定義，因此可輕鬆找出屬性名稱或資料類型中的任何錯誤。
• 更易於維護：步驟屬性的變更可於 TestStand 的參數設定中指定，不必修改程式碼模組。
• 可輕鬆於 TestStand 外再使用：由於程式碼模組不依靠 TestStand API，因此不需修改也可於 TestStand 外使用此模組。

在可能的情況下，使用參數將所需資料傳遞至程式碼模組

然而，如果程式碼模組會根據步驟狀態動態來存取多種資料時，使用 API 直接存取屬性效果更好。 在此情況下，使用步進參數可能會產生冗長的參數清單，但清單中只有某些參數會真正用在不同條件上。

若確實在程式碼模組中使用 TestStand API，則可將參考作為參數傳遞至 SequenceContext 物件 (ThisContext)。SequenceContext 物件可存取所有其他 TestStand 物件，包含 TestStand 引擎與目前的 Runstate。若使用終止監控 (Termination Monitor) 或模態對話框 (Modal dialog) VI，則序列內容參考亦為必要。

使用 SequenceContext 來存取程式碼模組中的 TestStand API，並透過程式設計方式來存取資料

如要在 TestStand 外重複使用程式碼模組，應記得：只有在從 TestStand 序列呼叫模組時，才能取得任何使用 TestStand API 的操作。任何透過 API 從 TestStand 取得的資料均不可用。 如果在 TestStand 之外呼叫程式碼模組，則可先檢查 Sequence Context 參考是否為零，以便為取得測試資料的替代機制定義。 在 LabVIEW 中，可使用「非數字/路徑/參考數字？」功能，來回傳 Boolean 值（如圖 3 所示）。

使用非數字/路徑/參考數字？，針對非 TestStand 所用程式碼模組，來檢查 SequenceContext 物件參考有效性

於程式碼模組中處理大型資料集

在許多情況下，程式碼模組可透過量測或分析，來產生大量複雜資料。 避免將這類資料儲存於 TestStand 變數中，因為 TestStand 會在儲存資料時建立一份資料副本。 這些副本可能會降低執行效能，與/或造成記憶體不足的錯誤。 使用下列方法來管理大型資料集，且不需建立非必要性副本：

• 在程式碼模組中操作大型資料集，例如在擷取的相同程式碼模組中分析資料，且僅將所需結果傳回至 TestStand
• 在 TestStand 與程式碼模組之間傳遞資料指針。 針對 LabVIEW 程式碼模組，應使用資料值參考 (Data Value References, DVR)

處理程式碼模組中的序列終端

按下終止按鈕時，TestStand 將停止執行序列，並執行所有的清理 (Cleanup) 步驟。然而，如果執行對程式碼模組進行呼叫，則模組必須先完成執行作業，並將控制權回傳給 TestStand 才能終止序列。若程式碼模組的執行時間超過數秒，或模組等待條件（如使用者輸入）發生時，則使用者可能會認為已忽略終止指令。

若要解決此問題，可使用終止監控 (Termination Monitor) 功能，讓程式碼模組檢查並回應呼叫執行的終止狀態。舉例來說，電腦主機板測試的運送範例即使用模擬對話框中的終止監控功能（如下圖所示）。 若測試序列終止，則「檢查終止狀態 VI」(Check Termination state VI) 將回傳「錯誤」(False)，並停止迴圈。

請參閱終止監控範例，以進一步了解終止監控的使用方式。

處理錯誤

測試系統中的錯誤是指無法執行測試的非預期執行時間行為。當程式碼模組產生錯誤時，可將資訊回傳至測試序列，以確認接下來所要執行的動作，如終止執行、重複上一次測試，或提示測試操作人員。

若要提供 TestStand 程式碼模組的任何錯誤資訊，請使用步驟中的 Result.Error 容器（如下所示）。 TestStand 會在每個步驟之後自動檢查此屬性，以判斷是否發生錯誤。 使用者不需將錯誤資訊從 TestStand 傳遞至程式碼模組。若程式碼模組將錯誤回傳至 TestStand，則可執行分支至測試序列的其他部分，如「清理」(Cleanup) 步驟群組。

可使用 On Run-Time Error（位於 Station Options 的 Execution 分頁中）設定，來確認 TestStand 如何回應步驟錯誤。 一般而言，開發序列時應使用「顯示對話框」選項，以利進行除錯，因為此選項可中斷執行，並檢查序列的目前狀態。 針對已佈署的系統，可考慮使用「執行清理」或「忽略」選項，這樣就不需測試操作人員進行輸入。 測試結果會自動記錄錯誤資訊，以便找出錯誤原因。
 

將錯誤資訊傳遞至 Step.Result.Error 容器，以便在發生步驟錯誤時通知 TestStand

管理程式碼模組效能與記憶體使用率

TestStand 預設，執行檔案中的序列時，會將序列檔案中的所有程式碼模組載入至記憶體，並保持載入狀態，直到序列檔案關閉為止。 透過這些設定，如在載入模組的同時開始序列，可能會發生初始延遲。 然而，序列檔案的後續執行速度會更快，因為模組會保留在記憶體中。

可在步驟設定面板的「執行選項」(Run Options) 分頁中，設定程式碼模組的載入與卸載時間。一般而言，預設載入選項可提供最佳效能，但在某些情況下，若程式碼模組與動態載入載入選項搭配使用，則可達到較佳的載入效能。 不會在一般執行作業中呼叫的程式碼模組（例如僅在特定測試失敗後執行的診斷作業）應動態載入，因為在多數情況下，這些模組完全不需要載入。

當動態載入程式碼模組時，應注意 TestStand 在載入程式碼模組之前，不會回報程式碼模組的問題，代表長時間執行可能即將結束。然而，序列分析器可於執行之前先確認序列中沒有錯誤。 分析器將檢查靜態與動態載入的程式碼模組。

針對需要大量記憶體的程式碼模組，可修改預設的卸載選項，以減少總記憶體使用量。 舉例來說，將模組設定為步驟執行後卸載或序列執行後卸載。 然而這項變更將增加執行時間，因為 TestStand 必須針對後續每次呼叫來重新載入模組。如果可能的話，最好的替代方案是使用 64 位元版本的 TestStand，搭配更多實體記憶體的系統，這樣即使需要高記憶體使用率，也能達到最快的測試效能。

如果程式碼模組維持共用資料（例如靜態變數或 LabVIEW 功能全域變數），則修改卸載選項可能會改變行為，因為全域資料會在卸載模組時喪失。當變更卸載選項時，請務必將所需的資料傳遞至 TestStand 序列，或將序列儲存在一個更具永久性的地點，以防止資料喪失。

請參閱提升 NI TestStand 系統效能的最佳實務，以進一步了解如何為測試系統達到最佳效能。

程式碼模組的常見用途是介接測試硬體，以設定激發，並執行測試量測。 與硬體通訊的方法包含：

• 使用硬體驅動程式（如 NI-DAQmx）直接與硬體通訊。
• 使用儀器驅動程式，透過 VISA 或 IVI 硬體驅動程式，於儀器內部將指令傳遞至儀器。
所使用的通訊方式取決於所使用的硬體類型。 無論是哪一種通訊方式，進行特定驅動程式呼叫前，都必須開啟驅動程式的參考或工作階段，並在完成互動後關閉控點。

選擇管理硬體參考的方法

多數情況都必須以多重測試步驟與相同硬體通訊。為避免在每個程式碼模組中開關儀器工作階段，而對效能造成影響，請務必考慮針對硬體參考在測試序列中的管理方式。 常見的硬體參考管理方法有 2 種：

• 從程式碼模組呼叫初始化與關閉功能，即可手動管理硬體參考。
• 使用 Session Manager，也可自動管理硬體參考的生命週期。

如使用儀器驅動程式，或使用 VISA 或 IVI 驅動程式直接與儀器通訊，則使用 Session Manager，除非有直接控制硬體工作階段生命週期的特殊需求。 若使用如 DAQmx 的硬體驅動程式，則無法使用 Session Manager，而必須手動管理參考。

使用 TestStand 變數手動管理硬體參考

初始化儀器時，會將工作階段參考作為輸出參數傳遞至呼叫序列，接著再將參考儲存於變數中。 然後會將此變數做為輸入，傳遞至每一個需要存取儀器的步驟。

許多驅動程式（包含 NI-DAQmx、VISA 與多數儀器驅動程式）均使用 I/O Reference 資料類型，來儲存工作階段參考。使用 TestStand 中的 LabviewIOControl 資料類型，來儲存這些參考。 

使用 LabVIEWIOControl 類型的變數，在程式碼模組之間傳遞硬體參考（如 DAQ 工作參考）

在 TestStand 與程式碼模組之間明確傳遞儀器控點時，應將硬體參考儲存於本地變數中。 若硬體用於數個序列間，則將控點做為序列參數，傳遞至每一個需要參數的序列。 避免使用全域變數來儲存硬體參考，因為在使用參考前，可能難以確保儀器已初始化。

基於以下理由，使用「設定」步驟群組來初始化硬體，而「清理」步驟群組則可關閉硬體參考：

• 若使用者終止序列執行，硬體參考仍將關閉，因為終止執行時，清理步驟群組會始終保持執行。
• 由於設定與清理步驟群組會在所選步驟前後執行，因此可透過互動方式執行那些使用硬體參考的步驟。

使用設定與清理群組來初始化，並關閉硬體參考

使用 Session Manager 自動管理硬體參考

針對 VISA 與 IVI 儀器控點，可使用 Session Manager 來自動管理硬體參考。使用 Session Manager 有諸多優點，包括有：

• 減少偶合：不必在軟體元件間傳遞儀器控點變數。相反地，每個元件都會指定一個邏輯儀器名稱，來取得工作階段。
• 減少程式設計語言障礙：以不同語言撰寫的程式碼模組可共用相同的工作階段，不必傳遞可能難以轉換語言的控點。
• 生命週期控制：由於儀器工作階段為具有參考計數的 ActiveX 物件，因此可將工作階段的生命週期與 ActiveX 參考變數的生命週期互相連結，且不需在支援 ActiveX 參考變數的語言中明確關閉儀器。

Session Manager 會在建立工作階段後自動初始化控點，並在釋放最後的工作階段參考時自動關閉控點。程式碼模組與序列將傳遞邏輯名稱（如「DMM1」），以便從 Session Manager 取得工作階段物件，物件包含對應的儀器控點。

使用 Session Manager 時，應將工作階段物件儲存在 TestStand 物件參考變數中。 由於工作階段的生命週期與物件參考變數的生命週期相關，因此每次執行時，儀器控點都會初始化和關閉 1 次，無論有多少序列程式碼模組與子序列會存取同一工作階段。

在下列範例中，Get DMM 工作階段步驟會針對邏輯名稱，取得 DMM 的儀器工作階段物件參考。此步驟會將工作階段參考儲存在本地變數中，因此工作階段在序列執行期間，會保持初始化狀態。

使用 Session Manager 即可透過邏輯名稱來參考儀器。 Session Manager VI 會使用邏輯名稱，取得 DMM IO 參考

如欲進一步了解 Session Manager 的使用方式，請參閱<Program Files>\National Instruments\Shared\Session Manager 中的 NI Session Manager Help。

前一個範例序列從 LabVIEW 程式碼模組取得工作階段，而此程式碼模組會呼叫 Session Manager，而非直接呼叫 Session Manager，因為此範例已配置 LabVIEW Adapter，以便在個別流程中運行 VI。 如欲進一步了解 Session Manager 的使用方式，請參閱 <Program Files>\National Instruments\Shared\Session Manager 中的 NI Session Manager Help。

呼叫硬體驅動程式函式庫

若要與任何類型的硬體通訊，則必須使用驅動程式函式庫，其提供的功能可讓使用者透過程式設計語言，來執行多項作業。 使用驅動程式函式庫時，常會呼叫多個 VI 或功能來執行單一邏輯作業，例如進行量測或設定觸發器。 非直接從 TestStand 步驟呼叫函式庫功能，而是建立程式碼模組來執行此功能時，可提供多項優點：

• 避免對每個功能耗用步驟功能
• 在驅動程式呼叫與 TestStand 序列之間提供抽象層
• 可更輕鬆地在測試程式之間分享執行作業

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