前言：中文期刊網精心挑選了單元測試方法范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
單元測試方法范文1
摘 要:隨著汽車電子市場的快速發展，汽車控制器的電子控制單元(ECU)已越來越多，對ECU的功能測試也變得日趨復雜。為解決車載ECU功能測試，研究了基于控制器局域網絡(CAN)的ECU自動測試方法。以NI公司的軟硬件為開發平臺、CAN總線為通信平臺搭建測試系統與被測ECU形成閉環結構。通過CAN總線傳輸測試信息，可實現對同型號ECU的批量測試。此系統采用了新的測試方法來降低測試誤差，并支持ECU的流水線測試，大大降低了測試的復雜度，減少了工作量。同時，在完善仿真信號產生模塊和測試模塊用例庫后，也能適用于其他類型ECU的功能測試。
關鍵詞:
控制器局域網絡；電子控制單元；批量測試；汽車電子；車載網絡
中圖分類號: TP206.1 文獻標志碼:A
Abstract: With the rapid development of automotive electronic market, more and more Electronic Control Units (ECU) for vehicle controller appear and the functional test also becomes more complex. In order to solve the problem of ECU functional test, the ECUs automatic test method based on Controller Area Network (CAN) was studied. The system included the software and hardware platform of National Instrument (NI) and communication platform of CAN bus, by which the system and ECU formed a closed-loop structure. To transmit the test message through CAN bus, the system could achieve batch test of ECUs with the same type. By using the new test method, the system can reduce the test errors, and support assembly line test of ECU, which greatly reduces the complexity of ECU functional test and test work. At the same time, the system can also apply to other types of ECU functional test by improving the generation module of simulated signal and use case library.
Key words: Controller Area Network (CAN); Electric Control Unit (ECU); batch test; vehicle electronic; vehicle network
0 引言
隨著汽車電子的不斷發展，汽車已進入電子控制時代，其標志為電子控制單元(Electric Control Unit, ECU)的廣泛應用?，F如今，車輛上電控單元數量不斷增加，功能越發復雜，多個處理器之間相互連接、協調工作并共享信息構成了汽車車載互聯通信網絡。其中控制器局域網絡(Controller Area Network, CAN)是汽車中應用較多的現場總線。其良好的實時性、可靠性和經濟性能很好地滿足汽車ECU之間數據通信的需要，已成為最有發展前景的現場總線之一［1-2］。因此，帶CAN總線功能的ECU測試也將變得更加復雜。ECU功能測試屬應用層功能測試范疇，是為了檢測ECU是否符合給定的協議規范，能否進行正常的控制工作。這種測試在系統級開發中占據了很大的比重，成為應用層測試中最為關鍵的部分［3］。
在傳統的ECU功能測試中，一種方式是利用測試面板產生ECU各種信號后連接到ECU各輸入引腳，觸發它的各驅動模塊進行控制工作，有專門的線路負責數據交換，但這樣的測試系統隨著傳感器數量的增多，連線非常困難，且需要高速的數據采集和信號調理設備，使整體成本增加［4-5］；另一種則改進了信號的產生方式，即通過虛擬儀器模擬ECU的控制信號來代替傳統的觸發信號，采用人工對控制效果進行直接的觀察和記錄。這些測試方法都加大了測試過程中的測試誤差、復雜度和測試工作量，且無法進行自動測試和結果的自動生成，也不能同時對多個ECU進行測試，給ECU廠商進行批量生產時帶來很大的不便。
由此，引發了對新的測試方法的思考和探索。基于CAN總線的ECU功能測試方法以CAN總線的傳輸作為關鍵技術，采用閉環測試方法對同型號的ECU進行自動和批量測試。
1 基于CAN總線的ECU功能測試介紹
車載控制系統主要任務就是要解決車身電器設備的功能性問題，所以，首先應關注ECU是否能實現功能上的控制，即測試其是否滿足控制協議的要求。ECU在控制功能上包括了通信服務功能、傳送數據功能、診斷信息及標定信息功能、設備監控和網絡管理功能等，具體的要求規范則由各ECU生產廠商自行制定。
目前應用層協議制定分為以測試為重心的模式和以設計為重心的模式。不論哪種模式，控制器開發過程中，都需要通過測試來驗證功能的正確性，確定ECU工作正常并不干擾總線正常通信［6］。
由圖1的控制器開發“V”模式圖可見，控制器開發過程包括多個環節，其中的應用層功能測試是其重要組成部分，它包括ECU功能測試、網絡管理功能測試、故障診斷測試等，是進行實車測試前的重要環節。在引入CAN總線后，將大大降低ECU功能測試的復雜度和測試工作量，是CAN總線測試的重要組成部分［7］。
在基于CAN總線的ECU測試系統中，通信網絡是進行數據傳輸，實現各模塊協調工作的橋梁［8］。利用LabVIEW［5,7,11］虛擬儀器產生仿真信號代替數據采集卡采集的真實信號，并在此基礎上引入CAN總線作為測試的關鍵技術，充分發揮CAN總線在傳輸上的高可靠性和實時性等優點。通過總線對仿真信號的測試報文進行有效傳輸，如表1所示。
表1中：Message表示報文名稱；ID表示報文仲裁場；DLC表示報文長度；Data表示報文數據。
將報文與同型號ECU進行連接，形成閉環測試結構，模擬實車中ECU的各種傳感器信號來驅動其進行控制工作（于3.2節詳細描述），將仿真報文數據和CAN總線上反饋回來的ECU控制報文數據進行解析，提取出Data的值，并自動進行多次對比和測試后，在人機界面上對測試結果和各種信號量進行直觀顯示，并利用測試結果自動生成測試報告，優化和改進了傳統的測試方法。
2 設計方案
此方法采用仿真信號序列代替采集卡采集的真實信號，利用CAN總線的特點對數據進行傳輸，并將整個測試構建成閉環結構，大大降低測試的復雜性。
2.1 方法總體框架
由CAN2.0協議可知，CAN報文的基本要素是報文ID、周期和信號與消息的映射關系。因此對ECU的協議功能測試，主要任務就是測試ID、消息周期、確定信號與消息的映射關系是否滿足要求，并測試在循環執行多次之后，ECU是否具備在控制功能上的穩定性［8］。
選用以LabVIEW為軟件平臺實現ECU的功能測試。測試系統整體框架包括三部分：上位機仿真和測試、CAN網絡和底層待測ECU模塊。如圖2所示。
工業計算機仿真給定ECU的各種信號量，驅動ECU進行控制工作。由于各ECU之間是相互獨立的，“測試與結果顯示模塊”采集不同ECU廣播的控制信息，并通過ID對它們進行識別。對采集到的控制信息進行分析、對比原始輸入來判定各個ECU在功能控制中是否滿足協議要求。
具體測試方法如下：
首先，通過上位機LabVIEW模擬仿真信號（如：轉向燈信號、溫度信號等）,通過NI 6259板卡，與待測ECU各引腳進行對接；
然后，發送仿真信號，驅動ECU進行控制工作，并發送出相應的CAN控制信息；
再次，通過NI 8473s板卡與上位機LabVIEW進行對接，接收采集到的CAN報文，并通過LabVIEW實現報文的解析、處理和ECU控制效果的同步顯示；
最后，把原始仿真數據和處理后的數據進行對比，驗證ECU在功能控制上是否滿足預期效果，并對以上測試步驟循環多次，得出測試結論，生成測試文檔。
在此，根據測試大綱要求，選用一個由實驗室和整車廠聯合開發的ECU作為應用實例，仿真信號由模擬信號和開關量信號組成，主要分為：轉向燈信號、報警信號、狀態信號、門信號、溫度信號和壓力信號控制信號。具體的控制量與變化范圍因測試ECU功能要求進行定制化處理。測試ECU仿真控制信號如表2所示。
2.2 軟件設計流程
上位機軟件整體分為7部分：虛擬儀器配置、模擬信號仿真、同步信號顯示、測試結果顯示、系統數據判斷、數據處理、測試報告生成。模塊示意圖如圖3所示。
1）虛擬儀器配置。對測試時使用的板卡進行初始化配置，設定參數和使用通道。
2）模擬信號仿真。產生ECU仿真信號（如轉向燈信號，水溫信號等）。
3）同步信號顯示。將采集到的CAN報文，進行處理之后，在人機界面上進行控件顯示，方便測試者進行直接觀察和分析。
4）測試結果顯示。在人機界面上進行測試結果的顯示，以表格和BOOL數組的形式顯示出每個信號在多次測試之后的通過情況。
5）系統數據判斷。將處理后的CAN報文數據與預先保存的仿真信號數據進行對比，得出測試結果。
6）數據處理。處理NI 8473s板卡采集到的CAN報文，提取數據信息。
7）測試報告生成。在人機界面上顯示測試結果后，將測試結果以網頁（.html）格式的文檔進行保存，便于后期的分析和處理。
軟件設計流程如圖4所示。
3 系統分析
由圖2測試方法總體框架圖可知，此系統主要包含三部分：上位機仿真和測試、CAN網絡和底層待測ECU模塊。其中上位機仿真和測試模塊又分為仿真信號產生模塊和測試與結果顯示模塊兩部分。
3.1 仿真信號產生模塊
使用NI 6259板卡和上位機LabVIEW構建仿真信號產生模塊。此板卡可支持48路數字信號輸出和4路模擬信號輸出。在調用接口函數模塊后，可產生需要的仿真信號，在板卡對應引腳輸出對應電壓信號。
由表2的ECU控制信號表可知，此待測ECU具有兩種不同類型的信號：模擬信號和開關量信號。所以需要在LabVIEW中使用DAQmx各模塊仿真出ECU需要的模擬信號和開關量信號。
1）產生模擬仿真信號［10］。需要把模擬信號轉化為ECU能識別的電壓信號，一般范圍在5V以內。
如：仿真發動機冷卻水溫度信號，水溫與電壓之間的關系如圖5所示。
通過最小二乘法線性擬合得出公式：
y=－4×10－10x5+7×10－8x4－3×10－6x3+0.0002x2－0.0642x+4.2044
其中：y為輸出電壓值；x為冷卻水溫度值。
如：進氣歧管壓力信號，壓力與電壓之間的關系式：
V=V參（0.0023P-0.015）
其中：P為上位機模擬的壓力值；V參為參考電壓5V。關系如圖6如示。
由圖5~6可知模擬信號與電壓值之間的轉換特性，由上位機進行轉換后通過板卡進行輸出，傳遞對應電壓值到待測ECU,驅動其進行控制工作。
2）產生開關量仿真信號。
在LabVIEW中定義各種開關量信號，通過板卡產生高/低電平。一般情況下，ECU檢測到高邊信號（ECU有效電平分兩種：H、L，即高電平有效或低電平有效）后進行控制工作（一般情況下，ECU的高電平判斷電壓在2.5V~5V），控制信號的開啟或關閉，并同步使用CAN模塊廣播CAN報文。
如：DriverDoorStatus（左前門狀態）,根據ECU手冊可知，其為BOOL量，所以在前面板中放置一個BOOL型控件。在對信號進行操作處理后調用NI6259板卡的接口函數并配置通道信息，與此板卡進行通信，產生所需仿真信號（此功能是否正?？赏ㄟ^示波器進行驗證）。
3.2 待測ECU模塊
車載ECU控制功能工作原理：ECU外接12V工作電壓，在人為進行操作或發生狀態變化（如開啟轉向燈、水溫變化）時電路接通，然后產生電壓值傳遞到ECU的模擬輸入引腳，如圖7所示。
此系統使用板卡產生的各種電壓信號代替左側虛線部分圖中未見虛線，請補充或說明。，ECU檢測到信號后進行控制工作。
3.3 測試與結果顯示模塊
上位機LabVIEW調用NI 8473s板卡接口函數采集CAN報文［12］。根據ECU控制協議，對CAN報文進行解析、分析、處理，提取出周期、ID、DATA等控制信息。然后對比原始數據（3.1節部分），進行多次測試后，如果每次測試都全部通過，則判斷為Pass，否則為False，并在前面板中進行顯示。
其中：原始數據包括報文周期、ID和控制信號數據等；報文周期和ID由ECU控制協議決定；控制信號數據由仿真控制信號模塊在產生仿真信號時提供。
4 測試實現
測試ECU在控制功能上是否滿足給定的協議和規范，并測試在循環測試多次之后，ECU控制功能是否具有較好的穩定性。測試系統人機界面如圖8所示。
“仿真信號控制部分”產生表1的ECU控制信號?！癊CU控制顯示部分”是對接收到的CAN報文進行解析、處理之后用控件進行形象的顯示，并與“仿真信號控制部分”進行對比。結果顯示，在循環測試100次之后，信號量“左前門狀態”和“進氣歧管壓力信號”控制出錯，在BOOL數組和測試表格中都有明確顯示。“ECU控制顯示部分”顯示出“左前門狀態”燈不亮以及進氣歧管壓力信號數據不一致，這些也同樣說明了信號控制的錯誤。在生成的測試報告(.html格式)中也有明確顯示，如圖9所示。
從測試過程中得知，各個ECU的觸發電平有可能不一樣，大致在5V~12V。NI 6259板卡的工作電壓需小于10V，所以在需要觸發電平高于10V的ECU上進行測試時，則需要在板卡的輸出端加入一個增壓電路。
同時，為了保證測試的正確性，在使用示波器確認仿真部分的輸出電壓無誤后，采用車載網絡測試專用工具CANoe對ECU控制報文進行監測，觀察結果如圖10如示。
由圖8和圖10可知，使用CANoe監測的總線報文與測試系統監測到的報文一致，驗證了本文所設計測試方法的可行性和準確性。在對比分析圖8和圖10中的監測數據，驗證了數據一致性和通信協議的可行性。
根據不同ECU的控制協議，制定不同的仿真信號產生模塊和測試模塊，并在使用過程中，不斷完善ECU的測試用例庫，在完善后進行不同ECU功能測試時，進行規格選擇后，即可實現對不同ECU的功能測試。
5 結語
本文介紹了ECU功能測試的現狀，優化和改進了傳統測試方法。此方法以仿真信號代替采集的真實信號來驅動ECU進行控制工作，并引入閉環結構和CAN總線，使測試過程更加簡單和智能化。所測結果準確可靠，能運用于ECU生產線，提高ECU批量測試的工作效率，為整車廠進行ECU測試帶來了方便。在完善仿真信號模塊和測試模塊用例庫后可擴展到對不同型號ECU的功能測試。同時，此方法的思想，還可以應用于車載網絡的測試、故障診斷等方面，具有較好的理論價值和實際意義。
參考文獻:
[1]
夏巍，嚴輝，丁剛.CAN網絡的實時性與可靠性的研究［J］.安徽建筑工業學院學報：自然科學版,2007,15(1):65-68.
[2]
KONG FENG, ZHANG LIYAN, ZENG JIE, et al. Automatic measurement and control system for vehicle ECU based on CAN bus ［C］// Proceedings of the IEEE International Conference on Automation and Logistics. Washington, DC: IEEE Computer Society, 2007: 964-968.
[3]
王立萍.CAN網絡在汽車控制方法的應用［J］.工業儀表與自動化裝置,2009(5):77-79.
[4]
WU WEI-BIN, HONG T S, LUO CAI-RU, et al. Hardware-in-loop of alternative fuel engine ECU ［C］// Proceedings of the Second International Conference on Computer Modeling and Simulation. Washington, DC: IEEE Computer Society, 2010: 291-294.
[5]
陳彥豐，朱君.基于PXI的汽車測試方案［J］.汽車制造與裝備,2005(3):44-46.
[6]
程躍,康勁松,徐國卿.一種車用CAN總線網絡測試系統的研究［J］.電子應用,2008,27(1):83-86.
[7]
梁銳.NI軟硬件平臺在汽車ECU開發和測試中的應用［J］.世界電子元器件,2007(12):61-63.
[8]
WEI WEN-XIONG, GUO JIANG-WEI, LIU SHENG-LONG, et al. Design of CAN communication network in automobile ECU testing system ［C］// Proceedings of the Second Pacific-Asia Conference on Circuits, Communications and System. Washington, DC: IEEE Computer Society, 2010: 1-3.
[9]
CAN Specification 2.0,Part A ［EB/OL］. ［2011-02-15］. can-cia.de/fileadmin/cia/specifications/CAN20A.pdf.
[10]
曹更彥.汽車燃氣發動機電控系統實時仿真技術研究［D］.重慶:重慶郵電大學,2009.
[11]
阮奇楨.我和LabVIEW［M］.北京:北京航空航天大學出版社,2009.
[12]
Society of Automotive Engineers. SAE J1939 ［EB/OL］. ［2011-03-03］. 省略/PDFs/manual/drehgeber/M36X8/M3658_J1939.pdf.
[13]
胡思德.汽車車載網絡（VAN/CAN/LIN）技術詳解［M］.北京：機械工業出版社，2006.
收稿日期:2011-06-16;修回日期:2011-08-21。
基金項目:
國家“核高基”重大專項（2009ZX01038-002-002-2）；重慶高校優秀成果轉化項目(KJZH08210)。
單元測試方法范文2
關鍵詞：軟件測試；單元測試；模擬對象
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)05-00ppp-0c
1 引言
隨著極限編程在實際軟件開發項目中的推廣，越來越多的項目開始采用測試驅動開發作為主要的軟件開發方法。單元測試不僅優化了軟件系統設計，還大大簡化了功能測試的工作量[1]。但是另一方面．更多的項目在開始不久就發現在很多情況下針對一個類編寫單元測試比較困難．隨著項目的進行，越來越多的代碼無法進行單元測試．到最后整個項目無法繼續采用測試驅動的方式進行開發。因此，要將測試驅動開發真正在整個項目里貫徹執行，必須有一種方法能夠相對容易的解決這些問題。本文將首先討論了單元測試和無法或很難進行單元測試的情況，然后引入Mock Object的概念，基于Mock Object實現單元測試。接下來討論在軟件開發過程中引入Mock Object對測試和設計的影響。最后簡述了Mock Object的局限性。
2 單元測試
2.1 什么是單元測試
單元測試是對程序中的單個子程序或過程進行測試的過程，也就是說，一開始并不是對整個程序進行測試，而是將注意力集中在對構成程序的較小模塊的測試上面[2]。單元測試從兩個角度進行測試：一是測試數據都是針對程序的功能來設計的黑盒測試；二是針對程序的邏輯結構來設計測試用例的白盒測試。
2.2 單元測試面對的難題
造成針對一個類難以進行單元測試的主要原因是因為這個類依賴于一些其它的難以測試的資源。主要有這三類最主要的資源：數據庫，第三方組件和網絡硬件資源。下面我們將對這三大類難以測試的資源進行分類討論。
2.2.1 數據庫
現在大部分的軟件項目都會采用數據庫作為數據存儲。常見的開發團隊會在每個開發人員的機器上安裝一個本地的數據庫，每個人針對自己的數據庫進行開發調試。這樣做的問題是：必須有一種方式同步數據庫的設計。如果有一個人修改了數據庫schema或者某個存儲過程，這個修改必須同步到所有開發者的本地數據庫以及測試服務器上。采用敏捷軟件開發的很多項目組往往會浪費大量的時間在數據庫設計同步上。更嚴重的是每周都會遇到由于數據庫設計不同步，修改沖突導致的問題導致整個項目的中心源碼庫在Auto Build時失敗。每個開發人員都有自己的測試數據，除了上面提到的需要把這些測試數據同步到所有開發機器和測試服務器上外，還面臨更重大的問題。因為測試用例需要修改數據庫，因此還必須準備一種機制能夠在每一個測試用例執行結束后重新將所有的測試數據調入數據庫。采用最簡單直接的方法就是在每個測試用例執行前都將數據庫清空，然后再將測試數據調入，這樣會大大減慢單元測試的時間。單元測試時間越長，開發者就越不愿意執行這些測試用例，單元測試所發揮的作用越小，這也是很多測試驅動項目最終無法進行到底的一個重要原因。另一個非常嚴重的問題是為了清理測試環境，在針對商業邏輯的測試用例中加入了大量的數據訪問層的代碼。采用這樣的方式強迫開發者在開發商業邏輯層的同時開發數據訪問層，并且嚴重降低了可讀性。
2.2.2 第三方組件或應用服務器
數據庫是最常見的第三方服務器。除此以外在越來越多的項目中使用第三方的組件和應用服務器。例如：客戶環境中的ERP系統,全球定位系統(GPS)的Web Service接口，繪圖引擎等。對于這些第三方提供的內容，造成難以編寫單元測試的最根本的原因有：一是系統不透明：對于大部分商業組件或者服務來說，一個很重要的內容是良好的封裝。但這個特性帶來的問題是在外界無法對其內部狀態進行控制和訪問。往往經過好幾個操作后才能在外部觀察到相應的變化。二是環境配置困難。由于項目組成員計算機配置不同，加入項目的時間不同，在項目中負責的內容不同導致無法為所有開發人員配置一個完全一致的環境。例如一個繪圖引擎的開發版的license是按照一個局域網內部同時使用的人員個數收費的，就不可能只為了能夠進行完整的單元測試就為只編寫商業邏輯層的開發人員也安裝一套。
2.2.3 網絡資源和硬件資源
在稍大一些的項目中都或多或少的用到一些網絡資源。例如將文件部署到遠程的webDAV服務器上同時很多項目還會用到一些硬件資源。常見的有打印機、指紋識別驗證或者條形碼閱讀器等。這些資源有兩大特點導致很難針對與他們相關的類編寫測試用例。
一是資源訪問沖突。很多網絡資源對于并發訪問的響應協調是通過鎖機制進行的，在實際項目中常見的是一個開發人員在調試本地代碼時導致遠端資源被鎖定導致其它開發者無法訪問這些資源。
二是環境可控因素。對于網絡資源和硬件資源相關代碼的測試與針對商業邏輯層代碼的測試最大的不同是環境的不確定性。訪問網絡資源有可能遇到的異常情況非常多，例如網絡忙造成訪問超時，也有可能建立鏈接后數據傳輸失敗，還有可能數據傳輸完成后校驗失敗。針對訪問這些資源的代碼進行的測試必須能夠覆蓋到所有可能出現的每一種情況。如果沒有一個可控，并且是全自動的環境輔助單元測試的話，這項任務基本上不可能完成。
3 模擬對象
3.1 什么是模擬對象
Mock這個單詞翻譯成中文大概的意思是假的，模擬的。如圖1所示：通過一個常見的對商業邏輯的測試描述了一個Mock Object。在圖中我們可以看出：測試代碼需要測試商業邏輯，而商業邏輯代碼需要通過IMyDataAccess接口訪問底層數據庫，這就是數據庫依賴問題。為了解決這個問題我們引入一個Mock Object，并將這個Mock Object而非真正的Data Access傳遞給商業邏輯代碼進行測試。這里的Mock Object不需要實現任何邏輯只需要根據商業邏輯的需要返回適當的內容就可以了。
圖1 使用Mock Object對商業邏輯進行測試
3.2 模擬對象實現單元測試應用實例
現在我們寫好了類AccountService，具體如下：
public class AccountService {
private AccountManager accountManager;
public void setAccountManager(AccountManager manager) {
this.accountManager = manager;
}
public void transfer(String senderId, String beneficiaryId, long amount) {
Account sender = this.accountManager.findAccountForUser(senderId);
Account beneficiary =
this.accountManager.findAccountForUser(beneficiaryId);
sender.debit(amount);
beneficiary.credit(amount);
this.accountManager.updateAccount(sender);
this.accountManager.updateAccount(beneficiary);
}}
現在我們想測試transfer方法，它內部調用的AccountManager的兩個方法。但是對于AccountManager來說，它只是個接口，如下：
public interface AccountManager {
Account findAccountForUser(String userId);
void updateAccount(Account account);
}
所以現在我們必須寫個MockAccountManager對象。而且里面的方法體都是非常簡單的，就是假定它就返回某某值。
我們這里還有Account類。
public class Account {
private String accountId;
private long balance;
public Account(String accountId, long initialBalance) {
this.accountId = accountId;
this.balance = initialBalance;
}public void debit(long amount) {
this.balance -= amount;
}
public void credit(long amount) {
this.balance += amount;
}
public long getBalance() {
return this.balance;
}
public String getAccountId() {
return accountId;
}}
public class AccountService1Tests extends TestCase {
public void testTransfer(){
AccountService as = new AccountService();
MockAccountManager mockAccountManager=new MockAccountManager();
Account accountA = new Account("A",3000);
Account accountB = new Account("B",2000);
mockAccountManager.addAccount(accountA);
mockAccountManager.addAccount(accountB);
as.setAccountManager(mockAccountManager);
as.transfer("A","B",1005);
assertEquals(accountA.getBalance(),1995);
assertEquals(accountB.getBalance(),3005);
}}
這里我們在假定AccountManager方法都工作正常的情況下，完成了對transfer方法的測試。
從以上代碼可以看出，采用Mock Object進行的單元測試基本上可以分為下面幾步：
(1)基于一個接口定義Mock并實現這個接口的所有函數。
(2)創建Mock Object的一個對象
(3)設置對象內部屬性
(4)告訴對象測試代碼希望看到的反應
(5)進行測試
(6)檢查Mock Object的確按照希望的順序進行工作。
3.3 模擬對象的優點
3.3.1 模擬對象作為測試手段的優點
Mock Object最直接的優點在于提供單元測試的質量和覆蓋率：
(1)只要在測試中對期待發生的問題指定好執行的順序引入Mock Object對象后的單元測試就是在一個完全可控的環境里進行的。也就是說我們再也不會無法定位一個“時隱時現”的bug。相反我們可以非常迅速的將問題定位在一個類的內部，而不是一個函數調用序列。
(2)于測試人員來說，最常見的問題是測試人員提交的bug無法在開發人員那里復現。有了Mock Object這個工具測試人員可以利用Mock Object明確的指定輸入和輸出編寫一個測試用例讓開發人員修復。
(3)超過8O％ 的異常處理代碼沒有被充分測試過。主要原因是在沒有Mock Object之前很多情況是無法由人工進行控制的，例如寫文件失敗網絡連接超時，數據庫數據傳輸失敗或者從網絡接收到的數據已經損壞。通過控制Mock Object我們很容易就可以模擬上面的這些情況。
3.3.2 模擬對象作為設計手段的優點
雖然Mock Object最直接的優點在于給予測試代碼更多的可控性和可操作性，它最大的優點在于對軟件設計的影響[3]。
(1)測試驅動開發與Mock Object一起使用，可以寫出低耦合高內聚，非常優雅干凈的代碼。
(2)強迫設計者放棄對第三方庫的強依賴關系，取而代之的是比較弱的依賴關系。
(3)設計人員可以將更大的注意力放在商業邏輯的實現和測試．由于Mock Object的存在，我們不需要實現數據訪問層就可以對商業邏輯進行測試。而商業邏輯才是任何系統中對于客戶最重要的內容，它的正確與否決定了整個系統是否能完成任務，它的穩定性決定了整個系統架構的穩定性。
(4)在項目初期，甚至是中期，將設計人員解放出來，不用對系統底層的基礎設施做出判斷。例如，在商業邏輯并不明確，需求還不穩定的時候，我們是更多根據感覺來做出很多重要的判斷的，而這些判斷往往導致比較關鍵的決定。例如，在項目之初，誰能夠明確的回答到底需要什么樣的數據庫？Oracle？SQL Server?還是XML文件？到底需要什么樣的隊列服務器 MSMQ還是IBM―MQ？由于Mock Object的引入，我們可以將這些決策推遲到商業邏輯層更加明確之后進行，從而可以獲得更加準確有針對性的答案。
3.4 模擬對象的局限性
Mock Object在實際項目中的應用存在一些限制，一些是由于Mock Object本身性質決定的，有一些則是由于其它類庫設計存在的缺陷導致的。
(1)一個典型的不是Mock Object的問題，而是類庫設計的問題。是Mock Object無法模擬比較深的對象樹。有一些第三方的類庫，尤其是一些消息處理函數的參數，提供的不是接口而是一些對象。往往這些對象內部有很多子對象，也就是我們常說的一棵大的對象樹。我們需要花費太多的精力去構造這些對象來進行模擬，時間消耗巨大。
(2)一般性而言，單元測試的粒度越細，功能測試的粒度就可以越粗[4]。但是引入Mock Object的單元測試仍然無法取代功能測試。一個很好的例子就是誤差積累的測試，哪怕每個單元的誤差都在可接收范圍內，我們仍然需要一個功能測試確保整體誤差也是可以接受的。
4 結束語
模擬對象解決了傳統單元測試的兩個問題：一是如何將需要測試的代碼與相關環境隔離；二是如何創建一個快速、可控的環境輔助測試開發。隨著模擬對象技術的成熟，基于模擬對象的單元測試會越來越廣泛地被采用。
參考文獻：
[1]Kent Beck.測試驅動開發[M].北京:中國電力出版社,2003.
[2]Myers.王峰，陳杰譯.軟件測試的藝術（第二版）[M]. 北京:機械工業出版社,2006.50-52.
[3]David Astels.崔凱,譯.測試驅動開發實用指南[M].北京:中國電力出版社,2004.120-130.
[4]Paul C Jorgensen.韓柯,杜旭濤,譯.軟件測試（第二版）[M].北京:機械工業出版社,2003.
單元測試方法范文3
本文就如何運用反饋——矯正手段提高教學目標效果談幾點看法。
一、在課前通過診斷性測試，獲得學生在學習新內容前的知識反饋，為上新課做好準備。
診斷性測試一般安排在新學期或新開課前進行，測試時間一般5～10分鐘，測試應側重于考查學習新課所需要掌握的基本知識和基本技能。例如，在上動物模擬人體手術實驗課前，先測試學生關于無菌技術和無菌原則方面的知識并補償，由此提高他們的學習外科手術的前提能力，最終提高實驗目標。
二、在課前或課后，通過形成性測試了解學生的達標情況，及時查漏補缺。
1、編制形成性測試題，包括課堂測試題和單元測試題，要確保適合各自的特點。
（1）課堂測試題，要適合在課堂教學中進行測試。課堂教學時間一般以二學時為單位，共80分鐘。其中用以進行課堂測試及反饋矯正的時間通常只有5分鐘，故編制此類試題要突出重點，考慮課堂操作的可行性，試題量不能過多。例如，在“復蘇”一章編制的課堂測試題為：①快速診斷心臟驟停的方法；②心肺初期復蘇的abc步驟；③心臟按壓有效的標志是什么；④心肺復蘇有效的指標是什么等。這些題中包括了本章的重要知識點，學生掌握后，在遇到心臟驟停病人時就會懂得如何去診斷和處理，而且試題量適中，便于在課堂上進行測試和矯正。
（2）單元測試題，即教師根據教學的情況，一般按章節劃分為一個教學單元，每學完一個單元后進行一次單元測試，以評價學生的單元達標情況。單元達標測試覆蓋的目標范圍較大，而且每一目標都應有相應的檢測題，測試時間為20～30分鐘，測試內容多時間少，因此編制此類題主張多用選擇題和判斷題，少用填空題、名詞解釋和問答題，以方便學生答題，做到既能檢測目標又不影響課堂授課。此處，通過定期的單元測試，又能促使學生經常系統地進行復習，有利于知識的鞏固和強化。
2、編制平行性測試題，此類試題適用于對矯正生的檢測。
即用以檢測單元測試中的未達標者，在經過補救矯正后是否已達標。編制此類別試題應與單元形成性測試題是同質不同形的，即用不同的試題形式去檢測同一目標。例如，檢測“補鉀原則”這一目標時，如果在單元形成測試中采用選擇形式，則在平行性測試中可采用判斷或填空題的形式進行檢測。
三、反饋——矯正是對經測試反饋的未達標者及時補救矯正，使其達標。
1、課堂反饋矯正。
課堂測試反饋一般采用提問、回答、接力填空等形式，其中最常用的是課堂提問的形式，而課堂提問的形式主要適合于對個別學生，這與目標教學要面向全體學生的宗旨是矛盾的，為了解決這一矛盾，在提問時應使所提問的學生具有代表性和隨機性。所謂代表性是指所提問的學生能代表全班學生中的某一部分，如優生、中等生或差生。要做到有計劃有目的地進行提問檢測，尤其對差生要多進行檢測矯正。隨機性主要是針對課堂教學的具體情況，在全班同學中隨機地進行提問。筆者曾在上“急性闌尾炎”一節時，發現一位同學在上課時開小差，當時立即對她進行提問檢測：“急性闌尾炎最有特征的癥狀是什么？”她回答是“腹痛”。這樣通過提問，可及時地使她調整思維、融入課堂。雖然她答得不全對，但是通過提問既能起到對她及時補救矯正的效果，同時也能引起其他同學的重視（尤其是對提問的這一問題的重視），結果在單元形成測試中全班同學都能答對這一題。這樣通過抓典型、抓代表，達到“牽一發而動全身”的效果，既能及時糾正課堂上出現的個別問題，又能調動全班同學的課堂積極性和主動性，因而能有效地提高教學目標達成度。
單元測試方法范文4
關鍵詞:軟件測試;案例教學;教學內容
中圖分類號:TP311 文獻標識碼:A文章編號:1009-3044(2010)09-2275-02
Teaching Methods of Software Testing Technology
GAO Zhi-sheng
(School of Mathematic and Computer, Xihua University, Chengdu 610039, China)
Abstract: Software testing is a course that teaches the software testing methods and means. Case teaching methods that runs through the whole software testing process with a single case is proposed. The corresponding teaching contents and experiment requirements are also introduced. Through the teaching methods, the studying interesting, the initiative and the capability of finishing the practical software testing projects are really improved.
Key words: software testing; case teaching; teaching contents
軟件開發過程中的質量問題是關系到軟件和軟件組織生存的重大問題,得到了越來越多的重視。目前在高校的軟件工程專業普遍開設有軟件測試相關課程。但是在具體教學實踐中,教師普遍感覺到有許多不如意的地方[1],具體表現在教學內容與具體應用脫節,學生對軟件測試認識有誤區,學生學習積極性不強、認為軟件測試是文字性課程,軟件測試過程如何展開,如何選擇測試工具,如何在教學中貫徹軟件測試管理思想等。
近年來關于怎樣進行軟件測試教學,引起了相關專家的重視和討論[1-4]。本文在總結前人的經驗基礎上,結合作者近幾年在軟件測試技術課程教學中的實踐提出了以一個具體項目案例貫穿整個教學過程,理論與實踐緊密結合的教學方法。
1 教學的目的和教學方法
軟件測試技術課程是本校軟件工程專業的一門專業必修課程,通過軟件知識體系的學習,使學生了解軟件測試的發展現狀,認識軟件測試的重要性,掌握軟件測試的方法和技術,熟悉軟件測試過程管理,從而具有獨立承擔軟件測試項目的實施能力,具有測試計劃、管理、實現和軟件質量保障的能力[3]。
針對以上教學目的,我們在軟件測試技術教學過程中引入一個具體測試項目案例貫穿整個教學過程的教學方法。第一課時,我們組織學生自由進行分組,每組5個人左右,每組確定一個名稱。要求每個小組在課程的前幾周完成同一個模擬題目“大學圖書館管理系統”的軟件開發。系統完成后,然后各個小組交叉進行測試對方開發的軟件系統。隨著課程的進度,主要要求學生完成軟件系統的單元測試,集成測試,功能測試和系統測試。單一的案例貫穿整個軟件項目測試過程的案例教學方法的優點是:
1)軟件測試的前期課程有“Java EE編程技術”,同時我們選擇圖書館管理系統作為開發對象,學生從技術上和業務需求上都具備快速完成該系統的能力。
2)相同的開發對象,互相測試對方開發的系統,有利于形成競爭,有利于調動學生的學習積極性。同時也有利于教師對學生完成的結果進行點評和組織課堂討論。
3)整個軟件測試課程,學生能夠完成對一個具體項目的全部測試過程,有利于促進學生系統地掌握軟件測試的技術方法,組織和過程。
2 教學過程
我們的教學過程主要包括以下5個階段,最初的幾周主要講解軟件測試原理,同時這個階段學生主要完成指定項目,然后是4個主要的軟件測試技術:單元測試,集成測試,功能測試和性能測試。軟件測試課程也會講解其他如回歸,壓力等其它測試技術,下面是我們課程重點講授的內容和要求。
2.1 軟件測試原理
本階段主要講授軟件測試技術的基本概念,使學生掌握基本的軟件測試原理。包括軟件測試的重要性,軟件評測師的職業規劃,軟件質量的概念等基本概念,重點講授的內容是白盒測試及用例的設計和黑盒測試及用例的設計兩個章節。白盒測試主要包括邏輯覆蓋和基本路徑覆蓋兩種用例設計方法,邏輯覆蓋又分為語句、判定、條件、判定/條件、組合、路徑覆蓋等。黑盒測試的重點內容是等價類劃分,邊界值分析,因果圖,決策表和場景法。
本階段對學生的實踐要求是開發“大學圖書館管理系統”,由上課老師為學生統一提供系統的需求規格說明書,該系統的主要功能如圖1所示。要求學生結合對本校圖書借閱系統的使用和需求規格說明書,采用Java EE技術進行開發,系統采用典型的4層結構進行設計,如圖2所示,即運行在客戶端計算機上的客戶層組件、運行在Java EE服務器上的Web層組件、業務層組件和運行在EIS服務器上的企業信息系統(EIS)層軟件[4]。系統開發采用JSF+EJB3.0的架構,Glassfish為應用服務器,MySql提供數據庫服務。
2.2 單元測試
單元測試是對軟件最小組成單元的測試,是軟件開發過程中進行的最基本的測試。單元測試主要按照程序內部的結構測試程序,檢驗程序中的每條通路是否都能按預定要求正確工作。單元測試主要考慮各個模塊接口的輸入和輸出,模塊內部的數據結構,模塊的邊界條件,模塊的基本路徑和模塊的出錯處理。單元測試階段還講授代碼規范性檢查,代碼覆蓋率的檢查,代碼復雜度的計算和內存泄漏的檢查等。
完成單元測試的基本原理的學習后,要求學生交叉完成圖書館管理系統的單元測試,主要抽取系統中的核心函數進行測試。完成測試后要求每個小組提供單元測試計劃,單元測試用例和單元測試報告3個報告文檔。得到所有報告后,組織一次課堂討論,展示優秀小組的成果,分析原因總結經驗。單元測試工具要求采用JUnit,代碼規范和代碼質量分析采用Logitscope, Pruify用于分析代碼的內存問題。
2.3 集成測試
軟件各個單元通過單元測試之后,需要檢查各個單元之間的相互接口是否正確,就是集成測試。軟件集成測試主要考慮的問題是模塊間的數據傳遞是否正確,一個模塊的功能是否會對另一個模塊的功能產生錯誤的影響,全局數據結構是否有問題,塊組合起來的功能是否能滿足要求,集成后累積誤差是否被放大等[5]。關于軟件集成測試的原則、策略和用例設計等相關原理可參考其它相關文獻。
教授完集成測試相關原理后,我們要求每個小組負責人組織完成系統的集成測試。集成測試以一個EJB、Servlet或者JSF為基本單元,工具選擇Cactus和HttpUnit。完成集成測試后要求每個小組提交集成測試計劃、集成測試設計文檔和集成測試分析報告。收齊所有小組成果,組織學生進行討論。
2.4 功能測試
功能測試就是對產品的各功能進行驗證,根據功能測試用例,逐項測試,檢查產品是否達到用戶要求的功能。主要考慮系統的各個功能,一般從軟件產品的界面、架構出發,按照需求編寫測試用例,測試產品時是否達到用戶使用的需求。本階段主要讓學生采用WinRunner完成系統的功能測試,進行功能測試之前首先完成測試計劃和測試用例的設計。然后完成WinRunner的6個步驟:識別程序的GUI,建立測試腳本,完善測試腳本,在新版應用程序執行測試腳本,分析測試結果和回報缺陷。
2.5 性能測試
典型的性能測試主要是從系統的響應時間、吞吐量、系統資源利用率、并發用戶數、HTTP事務處理數/秒、會話數/秒和連接建立時間等方面衡量系統的性能。性能測試主要有壓力測試,容量測試和強度測試等。針對圖書館管理系統的特點,我們要求學生理解性能測試的重要性和困難性,掌握性能測試的基本概念和技術。在此技術上,我們要求學生使用LoadRunner完成系統的壓力測試。主要步驟是測試需求分析,制定測試策略和方案(重點是設計測試場景),使用VuGen創建腳本,在Controller中創建場景,運行場景,分析結果。完成后提交測試策略和方案報告,腳本和圖書館管理系統壓力測試報告。
3 結論
一個合格的軟件評測師要求具有編程能力、開發能力、溝通能力、管理能力、逆向思維能力等多種能力。怎樣在大學軟件測試技術教學中培養既有理論又能實踐的軟件測試從業人員是本文研究的動機。我們提出的基于同一案例貫穿整個軟件測試技術教學過程的教學方法,通過學生互測對方開發的軟件系統,相互對比,相互促進同時組織課堂討論,有效營造了主動學習的氣氛,增強了學生的學習積極性,培養了學生主動思考問題的能力。該方法是一個值得借鑒的軟件測試技術教學方法。
參考文獻:
[1] 李繪卓,唐峻,范勇.基于案例的軟件測試實驗教學[J].電腦知識與技術,2009,27(5):7820-7821.
[2] 屠紅蕾.軟件測試教學的點滴體會[J].計算機教育,2008(10):124-125.
[3] 李亞.“軟件測試”教學探索與實踐[J].計算機教育,2008(6):14-15.
單元測試方法范文5
隨著信息化軍事技術的不斷發展，裝備仿真訓練軟件也獲得了迅速的發展，其規模越來越龐大、實現的功能越來越多、結構越來越復雜，裝備仿真訓練軟件的性能和可靠性也成為至關重要問題的。因此，軟件測試成為裝備仿真訓練軟件開發過程中一個必要的環節。依據一個科學的測試模型，使用先進的軟件測試技術對裝備仿真訓練軟件進行充分的測試，可以及時發現軟件程序中的錯誤，有效降低軟件錯誤出現的概率，驗證軟件功能的可行性，提高軟件的可靠性和安全性。
1 軟件測試模型
軟件測試是裝備仿真訓練軟件開發過程中一個不可缺少的重要步驟，而且隨著裝備仿真訓練軟件規模的增大、復雜度的增加，軟件測試也變得越來越重要。裝備仿真訓練軟件軟件測試過程與開發過程一樣，都能決定軟件的質量，而且測試過程的質量將直接影響測試結果的準確性和有效性。
在軟件開發幾十年的實踐過程中，人們總結了很多的開發模型，這些模型對于軟件開發過程具有很好的指導作用，由于測試與開發是緊密結合在一起的，所以軟件測試也需要有測試模型去指導實踐。軟件測試模型是將測試過程活動進行抽象的概念模型，用于定義測試活動的流程和方法，是確保軟件工程質量的重要手段。測試專家通過實踐總結出了很多很好的測試模型。這些模型將測試活動進行了抽象，明確了測試與開發之間的關系，更好的分析軟件測試在整個軟件研發中的參與度和工作過程，進而不斷完善軟件質量保證流程，提高軟件產品的質量，并成為了測試管理的重要參考依據。目前，主要的測試模型主要有以下4種：
1.1 V模型
V模型是將傳統測試模型瀑布模型改進后的一種測試模型，如圖1所示，從左到右，分別描述了軟件的基本開發過程和對應的測試行為，清楚地體現出每個測試階段和開發過程各階段的對應關系。但是在V模型當中，測試過程放在了編碼的下一個階段，這就容易使人誤解為測試是軟件開發的最后一個階段，而需求分析的檢驗工作也是在驗收測試才能進行。
1.2 W模型
W模型由兩個V模型組成，分別代表測試與開發過程，非常明確的標注了生產周期中開發與測試之間的對應關系，如圖2所示。但是在W模型中測試和開發也保持著一種線性的前后關系，上一階段工作完全結束，才能正式開始下一階段的工作，這樣就無法支持迭代、自發性以及變更性調整等情況。
1.3 H模型
H模型形成了一個完整獨立的測試過程，并且將測試準備活動和測試執行活動清晰的區別出來，如圖3所示。圖中僅僅演示了在整個生命周期中某個層次上的一次測試“微循環”，圖中的“其他流程”可以是任意開發流程。H模型的特點是軟件測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程并發地進行。當某個測試點就緒時，軟件測試即從測試準備階段進入測試執行階段。
2 裝備仿真軟件測試的特點及關鍵問題
2.1 裝備仿真軟件測試的特點
裝備仿真訓練軟件是一個由系統、分系統/子系統、模塊組成的復雜系統，并隨著系統和操作功能的增多，復雜程度也在增加，系統的好壞歸根結底是由各個分系統和各個模塊的好壞決定的，對各個分系統和各個模塊的測試是一個非常重要的環節。裝備仿真訓練軟件測試具有以下6個特點：
2.1.1 裝備仿真訓練軟件測試主要分為三個階段
從軟件生命周期全過程來看，軟件測試可分為單元測試、功能測試、集成測試、性能測試、系統測試、配置測試、回歸測試等階段。根據裝備仿真訓練軟件的結構、規模、類型和安全性關鍵等級等方面的特點，確定裝備仿真訓練軟件測試主要分為單元測試、集成測試和系統測試三個階段。
2.1.2 單元測試是裝備仿真訓練軟件的測試重點
裝備仿真訓練軟件測試是一項針對性很強的工作，即使對同一類型的功能，可能由于不同型號任務的要求，功能實現也會有所差異，因此要求重點進行單元測試。單元測試是根據詳細設計和源程序，了解每個最小模塊的輸入、輸出條件和邏輯結構是否正確合理。單元測試通常應對模塊內所有控制路徑設計測試用例，以便發現錯誤。
2.1.3 裝備仿真訓練軟件程序內部結構復雜，路徑組合數目龐大
程序的三種基本結構分別是：順序結構、分支結構和循環結構，裝備仿真訓練軟件最小組成模塊的內部程序都可看作是這三種結構按不同方式組合的產物，這其中包含大量多重選擇和循環嵌套的程序，而且模塊與模塊之間存在著大量的交互，所以程序內部包含的不同路徑數目可能是天文數字，尤其對大規模復雜的裝備仿真訓練軟件，窮舉所有的路徑是不可能的，需要根據實際情況去選擇適合的覆蓋測試方法。
2.1.4 裝備仿真訓練軟件黑盒測試用例數量龐大
裝備仿真訓練軟件中包含了不同專業的多個分系統，每個分系統又由多個子系統和模塊組成，其中包含的參數數量龐大，參數與參數之間的進行組合之后的數量將更加龐大，而軟件運行出現的故障時，更多的情況是由于多個參數的相互作用的原因，所以，要想充分考慮到參數與參數之間的關系，需要的測試用例數量是無窮盡的。
2.1.5 裝備仿真訓練軟件測試一般需要特定的測試環境支持
裝備仿真訓練軟件測試可以采用靜態測試方法和動態測試方法。其中，靜態測試以人工檢查為主，不需要特定的測試環境;而動態測試則需要建立驅動軟件模塊執行的測試環境，支持軟件模塊的參數輸入和輸出結果的可視化。
2.1.6 裝備仿真訓練軟件測試一般采用白盒測試與黑盒測試相結合的方法
一般采用白盒測試方法來測試裝備仿真訓練軟件程序內部的邏輯結構;裝備仿真軟件的功能測試部分則需要采用黑盒測試方法。
2.2 裝備仿真軟件測試的關鍵問題
軟件測試的目標是發現軟件中可能存在的設計缺陷和錯誤。測試時驗證得越全面，軟件中可能存在的缺陷就會越少，而每一個項目、每一個軟件的測試都會有不同的特點和測試關鍵問題，測試工作要根據軟件的特點和關鍵問題，設計適合該軟件的測試。裝備仿真訓練軟件測試的關鍵問題主要有以下4點：
2.2.1 測試工作必須由非開發人員來完成
由于許多開發單位對軟件測試的認識水平不夠，自己設計、自己編程、自己測試、自己維護的現象還比較普遍，這樣的結果就是導致測試結果不理想，沒有達到測試的要求。所以，為了保證測試質量，裝備仿真訓練軟件的測試工作必須由非開發人員來進行，保證的效果。
2.2.2 在白盒測試中，采用基本路徑測試方法解決路徑覆蓋率問題
在裝備仿真訓練軟件結構中，路徑組合是一個龐大的數字，所以要在測試中覆蓋所有路徑是不可能的，需要把覆蓋的路徑壓縮到一定范圍內。如：程序的循環部分可以只循環一次。因此，在路徑覆蓋測試上，我們選擇基本路徑測試法。
2.2.3 在黑盒測試中，采用組合覆蓋測試方法解決測試用例無窮盡問題
由于裝備仿真訓練軟件中參數與參數的組合數量龐大，無法設計無窮盡的測試用例滿足覆蓋率問題，為此，采用組合覆蓋測試方法，不僅可以充分考慮到軟件中參數與參數之間的相互作用，更重要的是能以最少的測試用例實現最大程度的覆蓋，具有較好的測試效果。
2.2.4 要有必要的測試文檔
沒有文檔的項目是一個不成功的項目，同樣，沒有文檔的測試也不會是一個成功的測試。測試工作的計劃、設計、實現和問題報告都要以文檔的形式記錄下來留存，方便同項目組人員進行閱讀和修改，更重要的是對于后續同類項目是資源的積累過程和設計的改進依據。
3 裝備仿真軟件測試模型
測試過程模型定義了測試的流程和方法，為測試工作提供了指導。但是傳統的測試模型各有長短，不可能適合所有的測試軟件，軟件測試模型因測試軟件的不同而不同，所以，本文通過對傳統的測試過程模型進行的分析和探討，同時研究分析了裝備仿真訓練軟件的實際情況，進而得到了適合裝備仿真軟件的測試模型，然后從該模型出發，完善軟件測試工作流程。裝備仿真訓練軟件測試模型是一個包含了軟件文檔審查、代碼靜態分析和審查、單元測試、子系統集成測試、系統測試和驗收測試的綜合測試模型，如圖4所示。
3.1 測試準備
測試準備階段是在測試實施之前，構造執行測試所需的要素，這些要素通常包括軟件開發文檔、軟件開發程序、實際執行測試所需的軟件、準備測試環境和測試工具;同時還要為測試過程準備適當的測試用例。
3.2 單元測試
裝備仿真訓練軟件單元測試部分包含靜態測試和動態測試兩個部分。其中靜態測試的對象是裝備仿真訓練軟件單元模塊的文檔和程序代碼，主要通過文檔審查、代碼審查、代碼靜態分析等方法來確保軟件需求和設計文檔的正確性、代碼的規范性、設計或實現的正確性。而軟件結構和功能方面的缺陷則需要采用動態測試的方法來完成。
裝備仿真訓練軟件單元模塊動態測試采用黑盒測試和白盒測試相結合的方法，從模塊級檢查軟件的功能、性能、接口和其他約束條件是否滿足需求。白盒測試技術主要測試每個單元內部邏輯結構的覆蓋率，黑盒測試技術測試模塊單元功能滿足需求情況。
3.3 集成測試
集成測試主要檢驗裝備仿真訓練軟件中經過單元測試的模塊和子系統各部分工作是否實現了相應技術指標、達到了相應的要求。在裝備仿真訓練軟件集成測試部分，既可以彌補單元測試中沒有測試到的Bug，又可以測試單元測試中沒有辦法測試的功能，如裝備仿真訓練軟件中前后臺集成之后的關聯功能。所以集成測試就是測試各個部件之間的配合情況，為系統測試提供基本保證。
裝備仿真訓練軟件的集成測試必須在所有模塊、子系統能夠正常運轉的情況下才能進行，一般采用的方法是數據驅動方法中的自底向上集成測試。具體的步驟是先測試組成子系統的模塊群，由于最底層的單元模塊都已經經過了單元測試，所以各個模塊可以向上集成為各個子系統;然后在此基礎上就可以測試各個子系統能否正常工作，以及進行各個子系統之間的測試工作。
3.4 系統測試
裝備仿真訓練軟件的系統測試是在集成測試的基礎上進行的，不僅是單純的測試軟件部分，而是將硬件、網絡和外設等其他要素結合進來進行綜合性測試。系統測試主要依據系統總體技術方案和需求說明書進行測試，目的是發現系統與用戶需求不符或矛盾的地方。
系統測試的測試類型一般包括功能測試、性能測試、負載測試、強度測試、容量測試、安全性測試、用戶界面測試、有效性測試、配置測試、故障恢復測試、安裝測試和回歸測試。而在裝備仿真訓練軟件的系統測試中，功能測試、性能測試、負載測試、安全性測試、有效性測試、配置測試、故障恢復測試是必須進行的，其他項目可以依據具體項目情況選擇性的進行。
3.5 驗收測試
在完成裝備仿真訓練軟件的系統測試之后，進行驗收測試。只有通過了驗收測試，才標志著項目的結束，軟件產品的完成。一般來說，驗收測試以用戶為主，主要驗證軟件的功能、性能以及其他特性是否與用戶要求相一致。
4 結束語
軟件測試的目的是通過測試來發現缺陷，找出缺陷的分布特征和出現的規律，以便在新的開發項目中改進設計結構，避免缺陷的出現，同時也能夠通過設計有針對性的檢測方法，改善軟件測試的有效性。隨著裝備仿真訓練軟件質量要求的提高，軟件測試在軟件開發中的地位越來越重要。裝備仿真訓練軟件測試模型是從傳統的軟件測試模型中提取出來的，適合裝備仿真訓練軟件的測試模型，不僅可以提高測試在軟件生命周期中的作用，還可以完善軟件部分的工作流程。
作者：鐘尚斌 來源：電子技術與軟件工程 2016年7期
單元測試方法范文6
0 引言
現代電子裝備的研制中，始終貫穿了兩個過程：即硬件研制和軟件的開發。這兩個過程其實是交織在一起，有些軟件的設計活動與硬件的設計還是迭代進行的。但又基于軟件設計與硬件設計各自不同的特性和規律，大多研制過程的程序文件是把軟件和硬件研制按照獨立的兩個過程來描述或界定的。這樣就帶來一個問題，很多設計人員以及管理人員有時就不清楚在研制的各階段中應該開展哪些軟件的設計工作，或者某個軟件開發過程，對應于裝備研制過程的哪個階段，以至于在研制計劃的安排上，軟件與硬件的設計進程不能很好地同步，造成時間上的延誤。目前，還未見相關資料對此加以論述，所以，理清電子裝備在研制各階段的軟件開發工作還是十分必要的。
1 論證階段
論證階段的工作是進行戰術技術指標、總體技術方案的論證及研制經費、保障條件、研制周期的預測，主要進行技術、經濟可行性研究。嵌入式軟件是由于計算機技術的發展應運而生，軟件是硬件功能的更為便捷高效的實現，所以，在論證階段，只需要論證人員了解基于嵌入式CPU、DSP等處理芯片和軟件的發展水平，并無實際具體的軟件開發工作。
2 方案階段
方案階段的主要工作是進行系統方案設計、關鍵技術攻關和新部件、分系統的試制與試驗，根據裝備的特點和需要進行模型樣機或原理性樣機研制與試驗。在此階段，要按照軟件工程化的要求，開展系統需求分析和設計，主要工作是按照GJB 2786A的相關要求分析系統對軟件的需求，確定軟件的實現和運行環境，對研制的軟件項目進行定義，形成軟件研制任務書。其具體工作是：
①通過獲取軟件所從屬的系統(或產品)的有關資料，分析系統的要求及實現環境;分析硬件和軟件的關系，進行可行性研究。②確定硬件環境和軟件環境。分析硬件和軟件的關系，定義硬件和軟件之間的接口;③確定系統的功能和性能要求，明確標識關鍵性要求;④將系統的功能和性能要求分配到軟件和硬件;⑤評估和確定軟件項目的安全關鍵性等級;⑥確定對關鍵計算機資源和資源余量的要求。例如：處理器、時間、存儲器、I/O通道等資源的約束。
若要進行原理樣機的研制，則還需針對原理樣機的需求，開展軟件需求分析、軟件設計和編碼。
3 工程研制階段
工程研制階段的主要工作是根據批準的《研制任務書》進行武器裝備的設計、試制、試驗工作。在這個階段軟件的開發工作依次是：
3.1 軟件需求分析 軟件需求分析階段的主要目的為每個計算機軟件配置項(CSCI)分配一組完整的功能、性能要求和一組完整的接口要求，并編制《軟件需求規格說明》和《接口需求規格說明》。主要工作內容有：
①根據《軟件研制任務書》定義的系統要求，建立軟件邏輯模型，自頂向下地把系統對軟件的需求逐層分解;②分配軟件的功能需求、性能需求、接口需求、操作需求、資源需求、確認測試需求、文檔需求、可靠性需求、安全保密需求、質量需求等，確保所有軟件需求分配到CSCI;③進行軟件安全關鍵性分析，提出安全性關鍵CSCI清單;④進行故障模式分析，確定可靠性冗余設計需求;⑤對資源的需求進行分析;⑥編制《軟件需求規格說明》和《接口需求規格說明》。
在軟件需求分析中，軟件的功能需求、性能需求、接口需求、操作需求等都對軟件的運行環境和資源提出了需求，所以，軟件需求分析須在《軟件研制任務書》下達后即可進行，以便給硬件的設計提供依據。
3.2 軟件設計 《軟件需求規格說明》通過評審后，即可進入軟件設計。其主要的工作有：
①將需求分析階段建立的邏輯模型轉化為能實現軟件需求的實現模型;②進行CSCI體系結構設計。設計軟件的總體層次結構，采用自頂向下的方法，把《軟件需求規格說明》和《接口需求規格說明》的要求逐項分解到計算機軟件配置項的計算機軟件部件(CSC);③設計各CSC接口相關的數據結構(或數據庫)、數據流和控制流;④進行安全性設計，使關鍵、重要部件符合軟件安全性要求;⑤如果軟件研制合同/研制任務書中對交付軟件的編程語言有明確規定，則軟件項目組應遵循其要求。否則應按照軟件繼承性、通用化和標準化的要求選取編程語言;⑥軟件項目組應確定所遵循的軟件編碼標準;⑦針對資源的要求進行設計，包括運算能力、時間、存儲、I/O通道、數據庫等資源;⑧進行CSCI詳細設計。將構成軟件系統的各個軟件部件(CSC)逐步細化，形成若干軟件單元(CSU);⑨采用程序流程圖或其它表示方法對各個軟件單元進行過程描述，包括算法和數據結構;⑩設計各軟件單元間的接口信息。
3.3 編碼和單元測試 軟件設計(含接口和數據庫設計)說明通過了評審，即可進入編碼和單元測試階段。其主要的工作有：
①根據軟件設計說明對各軟件單元進行編碼，確保軟件代碼正確實現了設計的邏輯并滿足相關的約束和要求;②軟件源代碼的編寫應遵循軟件編碼標準的要求;③對編碼完成的軟件單元進行編譯，采用合適的調試技術查找和糾正其中的錯誤;④采用靜態分析工具對軟件所有單元的源代碼進行靜態分析，找出其中的缺陷、錯誤、違背編碼標準之處，并加以分析和糾正;⑤按照GJB/Z 141《軍用軟件測試指南》的要求，對所有軟件單元進行動態測試;⑥使用單元測試工具，編制測試用例、開發單元測試輔助程序;⑦按照軟件文檔編制與管理指南的格式要求編制《軟件單元測試計劃》、《軟件單元測試說明》文檔;⑧執行單元測試用例和輔助程序，填寫單元測試記錄單;⑨確認和糾正單元測試中發現的問題，并進行單元回歸測試。
3.4 軟件集成和部件測試階段 軟件單元測試達到測試要求，通過評審后，即可進入軟件集成和部件測試階段。其主要的工作有：
①采用增量式的集成方法，將軟件單元逐步集成為軟件部件、構件直至軟件配置項;②按照GJB/Z 141《軍用軟件測試指南》的要求，對所有軟件部件進行測試;③編制《軟件部件測試計劃》;④按測試計劃建立部件集成測試環境，編寫測試用例和測試輔助程序;⑤編制《軟件部件測試說明》;⑥確認和糾正軟件部件測試中發現的問題，對文檔和代碼進行必要的修改，并通過回歸測試;⑦軟件部件測試需求覆蓋率和調用對覆蓋率均應達到100%，未達到測試覆蓋率指標的，應給出合理的說明。
3.5 軟件配置項(CSCI)測試 軟件部件測試報告通過了評審后即可進入軟件配置項(CSCI)測試。軟件配置項(CSCI)測試工作可以由研制單位軟件測試專門機構完成，也可以由用戶指定的第三方軟件測評機構完成。其主要內容有：
①根據軟件需求規格說明和軟件設計說明文檔，識別軟件測試需求;②編寫《軟件配置項測試計劃》和《軟件配置項測試說明》;③建立軟件配置項的測試環境;④按照軟件研制任務書中規定的測試類別，對識別出來的每個測試項分別編制測試用例和測試輔助程序。
3.6 軟件系統測試 軟件配置項測試報告通過了評審后即可進入軟件系統測試。由用戶指定的第三方軟件測評機構完成。其主要內容有：
①根據《軟件研制任務書》、《軟件需求規格說明》和《軟件設計說明》文檔，識別軟件測試需求;②建立系統測試環境;③編寫《系統測試計劃》和《系統測試說明》;④按照《軟件研制任務書》中規定的測試類別，對識別出來的每個測試項分別編制測試用例和測試輔助程序;⑤根據測試結果對設計文檔和代碼進行修改，并實施所有必需的回歸測試。
軟件單元測試和軟件集成和部件測試，可在搭建的仿真環境中進行，但對性能方面的測試，最好在真實的目標環境中進行，這就要求，硬件的組件(模塊)設計、組合或分系統設計在時間安排上與之相匹配。
軟件配置項(CSCI)測試和軟件系統測試，屬合格性測試，按照軟件工程的要求，嚴格地講，應該在正樣機鑒定之前進行。軟件配置項測試可在承制單位內部的軟件測試專門機構進行測試，如使用方有要求，需在由用戶指定的第三方軟件測評機構進行。軟件系統測試，一般在由用戶指定的第三方軟件測評機構進行。
在實際工作中，由于時間、經費等方面原因，經過使用方和承制方協商達成共識，也可在正樣機鑒定時不進行合格性測試，而在設計定型階段由定委指定軟件測評機構進行軟件測評即可。
4 設計定型階段
設計定型階段軟件工作主要是進行軟件測評。軟件測評，是通過軟件測試，來評價軟件是否滿足研制要求。軟件測評由定委指定的軟件測評機構完成。軟件測評和基地試驗、部隊試驗同步進行。
5 結束語
電子裝備的研制程序，是以傳統的硬件研制過程為主線進行的，而現代電子裝備，嵌入了軟件的研制過程，這是一個有別于硬件研制模式、又分屬于兩個團隊的研制過程，深入了解硬件研制和軟件研制過程各階段關聯性，對于科學合理安排研制計劃，有效管理研制進程，提高研制效率，都具有重要的作用。
