NI自動化測試技術(shù)展望:系統(tǒng)軟件棧

　　軟件是自動化測試系統(tǒng)的重要組成部分，軟件第一次被用于控制獨立的儀器到現(xiàn)在已有40多年。從那時起，軟件在自動化測試中的作用日益凸顯。事實上， 當(dāng)前大多數(shù)測試系統(tǒng)中，軟件開發(fā)費用通常是硬件成本費用的2到10倍以上。從許多測試工程企業(yè)的工程人員的組成比例即可看出這種情況，即雇傭的軟件工程師 比硬件工程師多。為了應(yīng)對軟件開發(fā)成本的上升及產(chǎn)品開發(fā)周期的縮短，當(dāng)前業(yè)界領(lǐng)先的公司都在強調(diào)設(shè)計一個強大的系統(tǒng)軟件棧，以確保他們在軟件方面的投入能 夠被延續(xù)下去，提高軟件資源的重用率。事實上， 2010年NI進行的測試經(jīng)理人調(diào)查報告顯示，測試經(jīng)理們對系統(tǒng)軟件方面投入更多的關(guān)注，其重要性在 2011年提高測試開發(fā)效率的策略中排名第二。

　　從系統(tǒng)軟件的角度來看，大多數(shù)公司正在遠離一體式的軟件棧，這種棧通常包含固定不變的代碼和直接調(diào)用儀器驅(qū)動函數(shù)。相反，他們正在探索一種模塊化的 軟件棧，這種棧的成員既獨立又緊密關(guān)聯(lián)，包括測試管理軟件、應(yīng)用軟件及驅(qū)動軟件等。這種類型的系統(tǒng)軟件?？蓭椭こ處熱槍γ總€領(lǐng)域的應(yīng)用選擇最佳的工具， 而且可在標準化的商用現(xiàn)成工具(Commercial Off The Shelf -COTS)和非現(xiàn)成的工具之間作出選擇。可以看到一個重要的趨勢，就是將模塊化的理念應(yīng)用到軟件棧的每一層之中，這包括越來越來多地使用過程模型 (Process Model)、代碼模塊庫以及硬件抽象層等。

　　測試管理軟件用于定義測試系統(tǒng)關(guān)鍵的自動控制策略及序列流程。其中過程模型是測試管理軟件層中的關(guān)鍵技術(shù)，因為過程模型能夠?qū)⒎菧y試任務(wù)與測試任務(wù) 分離，從而讓工程師們能夠輕松地在不同測試序列之間以及測試站之間對非測試任務(wù)進行標準化管理。非測試任務(wù)包括與企業(yè)的連接任務(wù)中的絕大部分，用于數(shù)據(jù)輸 入、質(zhì)量數(shù)據(jù)庫的數(shù)據(jù)記錄、與車間溝通以及生成可編輯的測試報告。有了這個模塊化框架，企業(yè)可以擁有幾個過程模型，這些過程模型能夠應(yīng)用在許多不同產(chǎn)品線 及所部署的成百上千的測試設(shè)備上。過程模型還可以在不影響測試任務(wù)的情況下簡化對測試站的非測試功能修改，從而減少了對已部署的測試站進行更新所需的時 間。例如，工程師們根據(jù)市場需求可以在順序執(zhí)行、批處理和并行執(zhí)行等測試過程模型中進行切換，從而快速改變測試站的執(zhí)行流程。

　　模塊化的軟件架構(gòu)可以增加靈活性，并縮短測試系統(tǒng)開發(fā)時間

　　應(yīng)用軟件層同樣重要，因為它直接影響了測試系統(tǒng)中測試相關(guān)的任務(wù)。很多企業(yè)已經(jīng)開始開發(fā)模塊化的測試代碼，也就是所謂的代碼模塊。這些模塊由測試管 理軟件進行調(diào)用，進行實際的測量和分析，來確定特定測試步驟的通過/失敗狀態(tài)。許多代碼模塊對不同類型的待測設(shè)備(Devices Under Test- DUT)執(zhí)行類似的I/O功能，因此在這方面，實現(xiàn)資源的重用以及使用基于團隊的開發(fā)方法分配開發(fā)任務(wù)非常重要。近來，業(yè)界已經(jīng)有越來越多的企業(yè)采用重用 測試代碼庫和更多的源代碼控制(Source Code Control-SCC)工具?，F(xiàn)在，許多應(yīng)用軟件供應(yīng)商在軟件中集成SCC工具和一些高級功能(如三方對比與合并，three-way diff/merging)，以適應(yīng)這種測試軟件開發(fā)趨勢。一些企業(yè)甚至設(shè)立專門的監(jiān)督機制以確保一定程度的資源重用和團隊開發(fā)，以防止重復(fù)開發(fā)和過分依 賴單一開發(fā)者完成所有的代碼開發(fā)。

　　此外，企業(yè)在應(yīng)用軟件層中對需求管理軟件工具的集成日益增多。這有助于確保根據(jù)設(shè)計需求進行一對一的測試項目覆蓋，這對有嚴格質(zhì)量標準的行業(yè)來說至 關(guān)重要。新的需求管理軟件在應(yīng)用軟件與需求管理環(huán)境(例如Telelogic DOORS)之間提供了一個連接，這極大地減少了在測試系統(tǒng)開發(fā)中跟蹤需求覆蓋所花的時間。

　　系統(tǒng)軟件棧的最后一個部分是硬件抽象層(Hardware Abstraction Layer -HAL)，它的需求和使用越來越多。HAL位于系統(tǒng)軟件棧的驅(qū)動軟件層，它將應(yīng)用軟件從儀器硬件中分離，最大限度減小移植和升級測試系統(tǒng)花費的時間和成 本。一般有兩種HAL設(shè)計方法：以儀器為中心或以特定應(yīng)用為中心。對于以儀器為中心的API，定義了一個內(nèi)部通用的以儀器為中心的API“標準”，可用于 多種類型的待測設(shè)備。

　　可互換虛擬儀器(Interchangeable Virtual Instruments -IVI)，是一個行業(yè)標準的HAL。從儀器為中心的抽象的觀點來看，頂層的測試應(yīng)用程序去調(diào)用一個以儀器為中心的API函數(shù)，這使所有儀器看起來很相似 (舉個例子，IviScope Configure AcquisitionType)。在以特定應(yīng)用為中心的方法中，測試應(yīng)用程序調(diào)用一個針對特定應(yīng)用的API，該API與需要執(zhí)行的測試的類型一致(例 如，LED測試)。HAL是開發(fā)和維護耦合度較低的測試系統(tǒng)時行之有效的方法，它能更好地解決產(chǎn)品和測試儀器生命周期不匹配的問題，避免測試儀器與測試代 碼耦合度過高。測試代碼與測試儀器的松散耦合，改善了測試系統(tǒng)的整體設(shè)計，使其在生命周期之內(nèi)更易于維護和擴展。

　　將軟件系統(tǒng)棧的模塊性融合到到每個軟件層之中，增強了靈活性，并提供了開發(fā)復(fù)雜生命周期管理策略的框架。這些策略有助于減少軟件開發(fā)時間及老化問題，對許多方面有所幫助，如產(chǎn)品功能拓展、系統(tǒng)升級、儀器技術(shù)增添計劃等。