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

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

　　從系統軟件的角度來(lái)看，大多數公司正在遠離一體式的軟件棧，這種棧通常包含固定不變的代碼和直接調用儀器驅動(dòng)函數。相反，他們正在探索一種模塊化的軟件棧，這種棧的成員既獨立又緊密關(guān)聯(lián)，包括測試管理軟件、應用軟件及驅動(dòng)軟件等。這種類(lèi)型的系統軟件棧可幫助工程師針對每個(gè)領(lǐng)域的應用選擇最佳的工具， 而且可在標準化的商用現成工具(Commercial Off The Shelf -COTS)和非現成的工具之間作出選擇?？梢钥吹揭粋€(gè)重要的趨勢，就是將模塊化的理念應用到軟件棧的每一層之中，這包括越來(lái)越來(lái)多地使用過(guò)程模型 (Process Model)、代碼模塊庫以及硬件抽象層等。

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

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

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

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

　　“我們創(chuàng )建了一個(gè)自動(dòng)化的設計驗證測試框架，其中包括一個(gè)硬件抽象層。這個(gè)框架使我們能夠靈活地配置測試硬件，而無(wú)需更改測試軟件的代碼。”　- Mohammad Ahmad, Manager, System Test and Verification, Thales Communications

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

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