（前四章閱讀筆記）------TestStand工業自動化測試管理

TestStand工業自動化測試管理
做者：胡典鋼

1.1 自動化測試
「 關鍵術語
Automated Test（自動化測試）、Automated Test System（自動化測試系統）、Testing Role（測試角色）、Test Operator（測試操做員）、Test Program（測試程序）、Unit Under Test（待測件）、Return On Investment（投資回報率）、Regression Test（迴歸測試）、Standard Automated Test System Architecture（標準自動化測試系統架構）、Application Development Environment（應用開發環境）、Instrument Driver（儀器驅動）、Test Management Software（測試管理軟件）、Commercial Off-The-Shelf（標準商用現成）

1.1 自動化測試
「 一個完整的自動化測試系統由測試站、儀器設備、測試軟件三個部分組成。

1.2 自動化測試系統
「 測試軟件組成
筆記：用戶界面；測試程序；自動糊測試框架；數據庫管理系統；數據分析系統；

1.2 自動化測試系統
「 用戶界面會設計得比較通用，使它能夠用於不一樣類型的產品。

1.2 自動化測試系統
「 自動化測試框架：與測試程序相反，自動化測試框架則包含通用的代碼，實現通用的功能，它適用於不一樣類型的UUT。自動化測試框架負責測試程序加載、用戶界面更新、產品序列號追蹤，甚至還接管一些和測試相關的任務，如生成報表、記錄數據庫、維護測試系統配置信息。在自動化測試框架內，經過編寫不一樣的測試程序，可實現不一樣產品的測試。所以，對於不一樣產品之間自動化測試系統的開發，更多的時間將花費在測試程序上面，自動化測試框架能夠最大程度地複用，縮短系統開發時間。

1.2 自動化測試系統
「 數據分析系統：數據分析系統從數據管理系統中提取數據，而後對結果進行分析，產品的不良率高、一致性差均可以藉助於數據分析系統查找緣由。

1.2 自動化測試系統
「 程序開發者負責開發測試程序，並根據技術員反饋的信息，調試並修改測試程序。程序開發者須要完成整個測試程序的開發，包括每一個具體測試項的代碼編寫工做，並依據產品規格設置測試項的上下限。程序開發者須要瞭解產品的每一個技術細節。測試程序的開發會在某個自動化測試框架內進行，而這個框架由架構師負責設計。

1.2 自動化測試系統
「 架構師負責自動化測試框架設計。自動化測試框架應該很是通用，這樣才能夠提供給不一樣的程序開發者使用。程序開發者再也不須要考慮如何設計用戶界面更新、產品序列號追蹤、報表生成、數據庫記錄這些由框架所定義的通用功能，而只須要專一於測試程序的開發。架構師必須對自動化測試自己有很是深的理解和技術積累，並熟練使用一種或多種語言來編寫用戶界面和開發測試工具，須要充分考慮框架的擴展、升級和性能優化。架構師不要求對特定產品很是熟悉，但要對產品所在行業有很好的總體瞭解和把握，同時須要考慮數據管理系統和數據分析系統的設計。

1.3 評估引入自動化測試
「 可視化的報表方便產品質量評估；

1.4 自動化測試趨勢
「 產品開發過程包括調研、開發、系統驗證、量產和後期維護五大階段

1.4 自動化測試趨勢
「 當各個組件設計完成並組裝成最終產品時，須要從系統角度對產品總體進行驗證，這包括產品性能參數驗證、功能性驗證、可靠性驗證，這個階段會進行小規模的試產。

1.4 自動化測試趨勢
「 以後是產品量產階段，包括產線複製，配套設施批量部署，產品大規模生產，這個階段出現的任何問題都有可能被無限放大，很是考驗企業的研發體系管理和質量管控體系規劃。最後是產品的後期維護階段，包括產品維修、市場反饋的產品缺陷修復、提早通知產品停產。

1.4 自動化測試趨勢
「 在產品調研和開發階段，以設計驗證測試爲主，評估方案可行性，確保設計的產品是正確的；而在系統驗證和量產階段，以質量驗證測試爲主，確保產品的功能正常、性能參數知足相關標準。

1.4 自動化測試趨勢
「 綜合測試的過程當中，又經常會引入迴歸測試（Regression Test）。好比，某個組件C1，單獨測試時其測試項T1經過，當組成子系統S1時，有可能在綜合測試中再次對組件C1執行測試項T1，由於有可能C1在子系統工做時會受到其餘組件的影響，致使其功能誤差甚至異常，迴歸測試能夠發現這些問題。另外，當子系統有問題時，也常常會採用迴歸測試以定位問題。

1.4 自動化測試趨勢
「 產品性能測試、功能測試、環境測試和負荷測試。

1.4 自動化測試趨勢
「 若是故障具備必定的表明性且返修率較高，則須要對返修產品作詳細檢測，生成檢測報告，並作故障統計。

1.4 自動化測試趨勢
「 舉另外一個以軟件爲中心的案例FPGA，做爲一種可編程邏輯器件，FPGA在短短20多年中從電子設計的外圍器件逐漸演變爲數字系統的核心。伴隨半導體工藝技術的進步，FPGA的設計技術取得了飛躍發展及突破，朝着高密度、高速度、寬頻帶，同時低電壓、低功耗、低成本的方向發展。FPGA技術最大的特色就在於經過軟件（硬件描述語言）定義硬件的功能，這種可重編程能力使得它可以高度定製化，輕鬆知足多元化市場需求。同時，FPGA社區提供愈來愈多的通用IP（知識產權）或客戶定製IP，以知足產品快速上市的要求。

1.5 標準自動化測試系統架構
「 。在測試和測量行業，最通用的自動化測試系統架構即五層結構模型，該模型自下而上分別是儀器設備、測試站、儀器驅動程序、應用開發環境、測試管理軟件

1.5 標準自動化測試系統架構
「 PXI（PCI eXtensions for Instrumentation）是一種堅固且基於PC的模塊化硬件平臺，是PCI總線在儀器領域的拓展，適用於測量和自動化系統。

1.5 標準自動化測試系統架構
「 VXI（VME eXtensions for Instrumentation）是板上儀器系統的另外一個標準，是VME總線在儀器領域的拓展

1.5 標準自動化測試系統架構
「 儀器驅動使用的常見的標準方法有「Plug and Play」（即插即用驅動PnP）、「Interchangeable Virtual Instrument」（可互換虛擬儀器驅動 IVI）、「Direct I/O」（直接 I/O）。

1.5 標準自動化測試系統架構
「 現代儀器的直接I/O通訊標準是經過「Virtual Instrument Software Architecture」（虛擬儀器軟件架構VISA）的API來實現的。VISA是一種工業標準通訊協議，不管是串口、GPIB，仍是USB，讀/寫ASCII字符串的VISA命令都是同樣的，所以VISA與接口無關，這使得開發人員用一種語言就能夠對不一樣接口的儀器進行編程。

2.1 初識TestStand
「 Test Management Software（測試管理軟件）、Sequence Editor（序列編輯器）、User Interface（用戶界面）、TestStand Engine（TestStand引擎）、Module Adapter（模塊適配器）、Step（步驟）、Step Group（步驟組）、Code Module（代碼模塊）、Sequence（序列）、SubSequence（子序列）、Sequence File（序列文件）2.1 初識TestStand
第1章介紹了標準自動化測試系統架構，測試管理軟件位於五層結構模型的最上層，用於管理和執行測試。

2.1 初識TestStand
「 TestStand擁有並行執行引擎，能夠極大地提升測試效率，知足高容量生產系統最嚴苛的生產要求。TestStand的特色概括以下：
測試管理和執行；
通用測試架構簡化測試軟件開發工做；
具備圖形化操做界面；
支持主流應用開發環境編寫的代碼模塊；
支持多線程並行測試；
內建測試策略；
具備自定製的用戶界面設計；
具備開放式的架構，可自定製；
自動生成ASCII、HTML、XML、ATML報表；
支持與Access、Oracle、SQL Server數據庫互聯。

2.2 TestStand經常使用術語
「 在TestStand中，經過序列文件（Sequence File）、主序列（Main Sequence）、子序列（Subsequence）、步驟組（Step Group）、步驟（Step）這種樹狀結構來組織不一樣的測試和操做（如圖2-3所示）。
圖2-3 TestStand測試和操做樹狀組織結構

2.2 TestStand經常使用術語
「 步驟是TestStand測試程序中的最小單元，再複雜的測試程序也是由許多步驟構成的。

2.2 TestStand經常使用術語
「 TestStand 將每一個序列分紅三個步驟組，分別是 Setup Group（設置組）、Main Group（主體組）、Cleanup Group（清理組）。

2.2 TestStand經常使用術語
「 設置組：通常包含初始化儀器、治具、待測件，以及資源分配的步驟。
主體組：序列的主體部分，包含大部分步驟如待測件的測試。
清理組：一般包含關閉系統電源，恢復測試儀器、治具、待測件到初始狀態，資源的釋放和關閉等操做。

2.3 TestStand組件
「 Sequence Editor（序列編輯器）、User Interface（用戶界面）、TestStand Engine（TestStand 引擎）、Module Adapters（模塊適配器）、TestStand Deployment Utility（TestStand 部署工具）

2.4 熟悉序列編輯器
「 若是發現界面調整得不理想，想恢復到初始的樣子，能夠經過菜單命令 「View Reset UIConfiguration」重置。

2.4 熟悉序列編輯器
「 序列窗格：顯示當前序列文件中的全部序列。
步驟列表窗格：在序列窗格任意選擇某一序列，在步驟列表窗格中會顯示該序列的全部步驟。
步驟設置窗格：在步驟列表窗格中任意選中某個步驟，相應地在步驟設置窗格能夠設置步驟屬性。
變量窗格：變量窗格顯示全部的變量和屬性。
插入面板：插入面板顯示了全部的步驟類型，選中某步驟類型，並經過拖拽的方式添加到步驟列表窗格中，即建立了該步驟類型的實例。
模板窗格：對經常使用的步驟、變量、序列預設置以後添加到模板窗格，它們將做爲模板，後續能夠直接使用模板建立實例，每一個實例都已經有了這些預設置信息，可簡化步驟設置工做。
筆記：窗格面板

2.4 熟悉序列編輯器
「 TestStand中有三個重要的目錄：﹤TestStand﹥、﹤TestStand Public﹥和﹤TestStand Application Data﹥。在本書中，涉及這三個重要路徑時一概用尖括號表示這是縮寫的文件路徑，如﹤TestStand Public﹥\Examples\Demo\。

2.4 熟悉序列編輯器
「 於﹤TestStand Public﹥\Examples\Demo\LabVIEW\Computer Motherboard Test目錄下。若是是LabWindows/CVI用戶，則使用序列文件﹤TestStand Public﹥\Examples\Demo\C\computer.seq，若是是DotNet 用戶，則使用序列文件 C：\Users\Public\Documents\National Instruments\TestStand 2013\Examples\Demo\DotNet\computer.seq。

2.4 熟悉序列編輯器
「 更多快捷方式能夠在TestStand幫助文檔中搜索關鍵詞 「Toolbar Buttons and Shortcuts」查找到。

2.4 熟悉序列編輯器
「 TestStand經過樹狀的結構對測試進行管理，層次化的結構有利於管理和代碼重用。TestStand最核心的組件是TestStand引擎，序列編輯器、用戶界面、模塊適配器都是經過TestStand API和它進行交互的。序列編輯器是TestStand中最重要的組成部分，絕大部分的測試管理工做都是在這裏完成的，做爲一個圖形化的開發平臺，它具備簡單易用的特色。最後對這個開發環境的視圖、佈局、序列執行進行了簡單介紹

第3章 TestStand系統和結構
「 目標
瞭解TestStand的系統和結構
瞭解TestStand過程模型
瞭解執行入口點和回調序列
瞭解TestStand開放式架構
關鍵術語
TestStand System and Architecture（TestStand系統和結構）、Process Model（過程模型）、Client Sequence File（客戶端序列文件）、Execution Entry Point（執行入口點）、Callback Sequence（回調序列）

3.3 TestStand開放式架構
「 過程模型、執行入口點、回調序列

第4章 動手建立序列
「 有些步驟類型能夠調用代碼模塊，而有些步驟類型卻只執行固定的操做，並不調用任何代碼模塊。

4.1 建立序列
「 關鍵術語
Sequence File（序列文件）、Sequence（序列）、Step Group（步驟組）、Step（步驟）、MainSequence（主序列）、SubSequence（子序列）、Steps Perform Defined Operations（執行固定操做的步驟）、Steps Called Code Module（調用代碼模塊的步驟）、Insertion Palette（插入面板）、Module Adapter（模塊適配器）、Properties Tab（屬性配置頁）、Built -in Properties（內置屬性）、Step-Specific Tabs（步驟特定配置頁）、Limit（限度）、Tests（測試）、Pass/Fail Test（合格/失敗測試）、Numeric Limit Test（數值限度測試）、Multiple Numeric Limit Test（多數值限度測試）、String Value Test（字符串測試）、Action（動做）、Statement（聲明）、Expression（表達式）、Label（標籤）、Message Popup（消息對話框）、Status（狀態）、Pass（合格）、Fail（失敗）、Done（完成）、Error（錯誤）、Flow Control（流程控制）、Synchronization（同步）

4.2 步驟內置屬性
「

4.2 步驟內置屬性
「

4.2 步驟內置屬性
「 「Properties Tab」（屬性配置頁）

4.2 步驟內置屬性
「 General Panel（通用面板）

4.2 步驟內置屬性
「 每種步驟類型都有其獨特的圖標，圖標會出如今步驟列表窗格中，也能夠收集一些圖標並添加到﹤TestStand Public﹥\Components\Icons\目錄下。

4.2 步驟內置屬性
「 運行選項面板（如圖4-7所示）中包含代碼模塊加載和卸載方式設置、運行模式、交互式執行步驟、結果收集以及對測試失敗和遇到錯誤時的處理方式。

4.2 步驟內置屬性
「 加載選項（Load Options）：聲明何時將代碼模塊加載至內存中。一共有三種模式，從字面上比較好理解：「Preload when opening sequence file」是在打開序列文件時就開始加載代碼模塊；「Preload when execution begins」是在序列開始執行時才加載代碼模塊，這也是默認的設置；「Load dynamically」是在執行到該步驟時才加載它的代碼模塊，這種模式能夠減小內存開銷，可是會影響序列執行的速度。

4.2 步驟內置屬性
「 運行模式（Run Mode）：一共有四種運行模式，分別是「Normal」、「Skip」、「Force to Pass」、「Force to Fail」，這對於調試頗有幫助
筆記：force迫使；強迫

4.2 步驟內置屬性
「 在交互模式下先決條件的評估（Precondition Evaluation in Interactive Mode）：聲明在交互模式下執行步驟時，先決條件是否起做用。

4.2 步驟內置屬性
「 Looping Panel（循環面板）
循環面板（如圖4-8所示）中可設置單個步驟的循環模式。好比，讓當前步驟執行固定次數，或者反覆執行該步驟數次直到狀態爲Pass或者Fail才結束。循環方式有如下四種。

4.2 步驟內置屬性
「 Post Actions Panel（後動做面板）
後動做指的是當前步驟執行結束後，TestStand根據步驟的執行狀態決定接下來進行什麼動做。後動做的不少選項能夠經過流程控制步驟來實現，所以不建議在後動做面板

4.2 步驟內置屬性
「 調用序列（Call sequence）：調用同一序列文件中的其餘序列。經過這種方式調用序列，不能給序列傳遞參數，因此更推薦的方式仍是用「Sequence Call」步驟類型。

4.2 步驟內置屬性
「 狀態表達式（Status Expression）：狀態表達式決定TestStand最終如何計算步驟狀態，它的數據類型是字符串。有些步驟類型，如Numeric Limit Test，狀態表達式由系統自動生成，不可輸入。

4.2 步驟內置屬性
「 Requirements Panel（需求面板）：需求面板將當前步驟和需求文檔中的某個ID關聯起來，只有安裝了Requirements Management軟件時纔有用。

4.2 步驟內置屬性
「 Additional Results Panel（額外結果面板）：TestStand每執行完一個步驟都會產生不少結果，它將結果放到一個特定的地方——結果列表，在結果列表裏的數據纔可能最終出如今報表或記錄到數據庫中。若是但願某些變量一樣出如今報表中，可使用額外結果面板先將它添加到結果列表裏

4.3 使用任意模塊適配器
「 在序列中，最重要的步驟就是「Tests」，一共有四種類型的測試步驟：Pass/Fail Test、Numeric Limit Test、Multiple Numeric Limit Test、String Value Test，它們將決定產品是否測試經過。

4.3 使用任意模塊適配器
「 觀察變量窗格中「Step」屬性，它包含了當前步驟的全部數據，除了「Step.Result.Error」、「Step.Result.Status」這些全部步驟類型都包含的基本屬性，它的比較重要的屬性有「Step.Result.PassFail」、「Step.DataSource

4.3 使用任意模塊適配器
「 在TestStand中第一次調用代碼模塊時，若是代碼模塊目錄不在TestStand的搜索路徑列表中且使用的不是絕對路徑，則TestStand會彈出文件沒有找到對話框，提示用戶選擇路徑方式，如圖4-21所示。通常狀況下，除非是特殊系統目錄下的文件，不然都會選擇第三種方式—— 「使用相對路徑」。這樣，一旦序列文件和代碼模塊一塊兒打包到其餘計算機或總體移動位置時，序列文件也能正確的加載代碼模塊，不會出現文件丟失的問題。

4.3 使用任意模塊適配器
「 關於代碼模塊路徑的問題，這裏多探討一下。當第一次加載任何一個代碼模塊時，TestStand會彈出文件沒有找到對話框，提示選擇該文件的路徑方式。可是該對話框會根據當前序列文件是否已保存到確切路徑而有所區別：如圖4-24所示若是是新建的序列文件而且未保存，文件沒有找到對話框只有兩個選項；只有當新建的序列文件保存到某個具體路徑下，文件沒有找到對話框中，纔會有第三個選項——使用相對路徑。由於新建的序列文件在未存盤以前是沒有一個確切的路徑的，當給測試步驟聲明代碼模塊時，TestStand沒法計算序列文件和代碼模塊之間的相對路徑關係，因此強烈建議用戶先保存序列文件，而後調用代碼模塊時在文件沒有找到對話框中選擇第三種方式——使用相對路徑。
圖4-24 文件沒有找到對話框
可是即便保存了序列文件，仍有可能在文件沒有找到對話框只出現兩個選項。
狀況一：序列文件的路徑爲E：\PassFailTest.seq，代碼模塊的路徑爲E：\Tests DLL Project\Tests.dll。序列文件所在的目錄「E：」是代碼模塊所在目錄「E：\Tests DLL Project」的上級目錄。這種狀況下，文件沒有找到對話框有三個選項，可使用相對路徑。
狀況二：序列文件的路徑爲E：\Temp\PassFailTest.seq，代碼模塊的路徑爲E：\Tests DLL Project\Tests.dll。序列文件所在的目錄「E：\Temp」並不是代碼模塊所在目錄「E：\Tests DLL Project」的上級目錄，這種狀況下，文件沒有找到對話框只有兩個選項。
因此通常建議將序列文件所在目錄置於代碼模塊的上一級目錄，這樣規範化以後利於維護代碼模塊的相對路徑關係。固然，若是有些代碼模塊，如DLL是第三方開發的且只能在固定的目錄下，這時在文件沒有找到對話框只有兩個可選項的狀況下，除非是特殊系統目錄下的文件，不然選擇第一種方式——將包含文件的目錄添加到搜索路徑列表中。這樣，一旦文件不在原來聲明的位置時，TestStand會自動去搜索路徑中尋找。建議在「Module」一欄中手動輸入相對路徑關係，如狀況二中，序列文件和DLL之間的相對路徑是「..\Tests DLL Project\Tests.dll」，如圖4-25所示。這樣即便序列文件不在代碼模塊的上一級目錄，把整個更上層的目錄總體打包或複製的話，也能保證代碼模塊正確加載。

4.3 使用任意模塊適配器
「 數值限度測試有三個特定配置頁：「Module」（模塊）、「Limits」（限度）、「DataSource」（數據源）。「模塊」頁面和以前合格/失敗測試是同樣的，用於聲明代碼模塊；「數據源」頁面，它的默認數據源是Step.Result

4.3 使用任意模塊適配器
「 Numeric；在「限度」頁面（如圖4-27所示），能夠設定限度值，選擇比較類型，默認比較類型是「GELE」，表示若是知足「Low Limit﹤= Data Source﹤= High Limit」（數據源在上下限之間），則測試經過。Low（下限）和High（上限）能夠是常量，也能夠是表達式，其餘比較類型還有大於等於、小於等於、等於、大於、小於等。
圖

4.3 使用任意模塊適配器
「 新建立序列文件並添加數值限度測試步驟，在模塊頁面一樣選擇「Tests.dll」，使用「Add」函數，根據Add函數原型double Add（double a，double b），先在變量窗格中建立兩個局部變量「x」和「y」，數據類型爲數值型，初始值爲默認值「0」。添加好以後，局部變量窗格應該看起來是圖4-28所示的樣子。
圖4-28 建立局部變量
在參數列表區域配置參數，「Return Value」參數的「Value Expression」中填寫「Step.Result.Numeric」，即代碼模塊的輸出傳遞給該屬性。對於參數列表中的每一個參數，選中後能夠在相應的參數配置區對它進行配置，如圖4-29所示。
圖4-29 數值限度測試步驟特定配置頁—模塊

4.3 使用任意模塊適配器
「 數值限度測試步驟中，重要屬性有「Step.Result.Measurment」、「Step.NumericArray」、「Step.DataSourceArray」。

4.3 使用任意模塊適配器
「 多數值限度測試一樣有三個特定配置頁：模塊、限度、數據源，默認數據源是「Step.NumericArray」

4.3 使用任意模塊適配器
「 在TestStand中，會強制要求預設定字符串的緩存大小，能夠設置一個稍大的值，如100，如圖4-37所示。
它的默認數據源是「Step.Result.String」，而在限度頁面中，比較類型能夠選擇「Ignore Case」（忽略大小寫）或「Case Sensitive」，在「Expected String Value」中輸入預期的字符串，字符串能夠是常量或表達式，如圖4-38所示。

4.3 使用任意模塊適配器
「 動做是TestStand中用的很是頻繁的步驟類型。動做類型一樣調用代碼模塊，但它執行某一動做，如初始化儀器、鏈接數據庫、加載配置文件等，它不須要將結果和限度進行比較，所以不一樣於上述測試步驟的地方在於測試步驟執行完的狀態是合格或失敗，而動做步驟的狀態就是「Done」（完成）。

4.3 使用任意模塊適配器
「 ，選擇該VI以後，在代碼模塊預覽區域能夠預覽其原型，包括VI的接線端和描述信息

4.3 使用任意模塊適配器
「 值得注意的是error out參數，在LabVIEW中，它的數據類型是簇，包含三個元素，數據類型分別是布爾、數值、字符串類型。TestStand默認數據類型「Error」能夠和它很好地匹配起來。通常將VI的錯誤輸出傳遞給當前步驟的屬性「Step.Result.Error」，這樣一旦VI中產生錯誤，當前步驟的狀態就變成「Error」，TestStand會啓動錯誤處理機制，彈出錯誤對話框或者直接結束序列執行，避免錯誤的擴大

4.3 使用任意模塊適配器
「 序列編輯器中調試時，能夠進入LabVIEW應用開發環境，並利用LabVIEW的調試工具進行調試，這給開發人員調試帶來極大的便利，可見TestStand模塊適配器的強大之處

4.4 調用特定模塊適配器
「 就序列文件自己而言，它的完整測試過程是從主序列開始一步步往下執行，遇到調用序列步驟時，TestStand會進入子序列中並逐步執行子序列中的每一個步驟，子序列執行完以後再返回到主序列，並接着往下執行。一般，序列調用步驟的狀態爲「Passed」或「Failed」，子序列中任何步驟失敗都將致使它的狀態爲「Failed」，而若是有步驟產生運行時錯誤，它的狀態將爲「Error」。

4.5 無模塊適配器
「 聲明步驟執行一個或多個TestStand表達式。表達式用於修改或設置TestStand中變量的值、對象的屬性。默認聲明步驟執行完後狀態爲「Done」，除非表達式出現錯誤，狀態被設置爲「Error」。

4.5 無模塊適配器
「 默認序列中的步驟是按順序執行的，而流程控制步驟能夠額外控制步驟的執行方式。好比，條件執行語句能夠選擇性地執行某些步驟，循環語句可使步驟屢次運行，Goto語句能夠直接跳轉，打破執行順序。若是讀者有過文本編程的經驗，對於這些語句應該並不陌生，它們的原理基本是相通的。大致上可將TestStand中的流程控制步驟分爲三類。

4.5 無模塊適配器
「 Select-Case步驟相似於文本語言中的Switch-Case語句。若是Select表達式的值與某個Case分支中的常量表達式的值相等，則執行該Case 分支。不一樣於文本語言中Switch -Case語句的地方在於：Select-Case步驟中，任什麼時候候，只要有一個Case分支匹配，則在執行完該分支後，馬上跳出整個Select-Case結構，即最多隻有一個Case分支被執行，而且它不須要Default默認分支。

4.5 無模塊適配器
「 在TestStand中通常會使用標籤做爲跳轉目標，標籤以後緊接着是相關的測試步驟，這樣作的好處是修改或刪除測試步驟時，不會影響Goto語句正常跳轉。Goto語句不可濫用，因爲它改變了序列的執行順序，增長了調試和追蹤的難度，而且屢次採用Goto語句跳轉，可能致使死循環。

4.5 無模塊適配器
「 Property Loader（屬性加載器）：在TestStand中有一個屬性導入導出工具（經過菜單命令「Tools»Import/Export Properties」訪問），它能夠導出序列中全部步驟的限度、變量、屬性並存儲到文件或數據庫中，而Property Loader能夠從文件或數據庫中導入這些數據