時間：2022-04-26 00:49:09
引言：易發表網憑借豐富的文秘實踐，為您精心挑選了九篇單元測試方法范例。如需獲取更多原創內容，可隨時聯系我們的客服老師。
關鍵詞：遺傳算法；模擬退火算法；自動化；單元測試
中圖分類號：TP311.53
隨著計算機技術的發展，計算機智能技術也逐漸得到了開發應用，生物智能、人工智能以及算計智能的聯合應用和優勢互補，使智能技術的應用更加有效。隨著計算機的普及，軟件產品已經深入人們生活工作的各個領域，成為日常工作、生活、娛樂的必不可少的組成部分。而對于軟件安全性能的要求則在很大程度上促進了軟件測試的發展。軟件測試是軟件安全性能和良好的使用性能的重要哦保證，貫穿于軟甲開發過程的始終，保證軟件開發每個階段的質量。
軟件的質量需要經過軟件功能測試才能得到保障，而單元測試則是軟件功能測試的基礎和前提，是軟件測試的起步環節。單元測試針對的對象是程序中最小的軟件模塊，一般是軟件開發人員通過編寫小段代碼，針對被測試代碼的某個較小較明確的功能進行測試，看其是否可以正常運行。
1 參數化單元測試
單元測試作為軟件測試的起步環節，同時也是不可或缺的環節，對軟件的質量起著至關重要的作用。在實際測試中，單元測試代碼的手動編寫工作是一件極其復雜且耗時的工作，并且所選測試實例不能保證覆蓋較大的代碼，具有很大的隨機性，進而降低單元測試的效率。
參數化單元測試將程序規格與測試用例生成分離，解決了傳統單元測試存在的弊端。運用參數化單元測試方法，程序要實現的功能需要人工書寫代碼，然后測試工具就會通過對測試代碼的分析和檢測，自動根據測試的實際路徑生成對應的實例和測試代碼，實現代碼的高覆蓋率。
2 基于遺傳算法的搜索策略
在退火算法的運行過程中溶入遺傳算法，稱為退火遺傳算法，依舊是說，所謂的退火遺傳算法，實際上是由退火算法和遺傳算法兩個部分組成，結合雙方各自的優點和特性，所得到的新的綜合性計算方法。
2.1 遺傳算法依據
遺傳算法的提出源于計算機發展初期提出的所謂“人工進化系統”，它是根據生物進化的特點，借鑒優勝劣汰的自然遺傳法則，參照達爾文進化論的理論思想而形成的一種不依賴具體問題的直接搜索方法，在運用遺傳算法進行數據計算時，不僅要用到進化學的概念，同時也要符合遺傳學說的基因遺傳原理。
運用遺傳算法進行計算時，一般要經過幾個基本步驟，即：初始化數據、數據的擇優選擇、隨機對選中的兩個數據進行交叉互換、根據遺產學說的基因變異原理所進行的個體數據變異、全局最優收斂，進而得出需要的結論或數據。
2.2 模擬退火算法依據
模擬退火算法是根據固體退火過程和組合優化問題之間的相似性而提出的。在對物質進行加熱處理時，物質組成中粒子之間的布朗運動加強，當加熱到一定程度時，溫度達到物質熔點，固體物質會轉化為液體形態。這時，對物體進行退火處理，使溫度降低，則物體的粒子運動減弱，并且會逐漸趨于平衡和有序，最終達到物質性質的穩定。
模擬退火算法運用溫度參數進行控制，當溫度較高時，數據運動變化劇烈，從而使解的區間變化較大，容易接受到較差解；當溫度降低，數據運動逐漸減緩時，解的區間也會逐漸趨于穩定，這時候就可以得到較為優良的解果，從而對遺傳算法的不足進行彌補。
2.3 退火遺傳算法依據
退火遺傳算法，是指以遺傳算法為主要運算方法，并在運算過程中引入模擬退火算法，使兩者達到優勢互補，進一步對群體進行優化調整。退火遺傳算法可以分為兩個組成部分：首先，運用遺傳算法的進化理論，產生一個相對較為優良的群體，然后利用模擬退火算法，對群體中的個體進行優化和調整。
（1）針對遺傳算子進行改進
所謂遺傳算子，是指在遺傳算法中，用來維持遺傳多樣性所使用的算子，遺傳多樣性是生物或數據演化過程中不可或缺的一個必要性質，遺傳算子在遺傳算法中類似于自然中的適者生存原則，對于個體的進化會產生巨大的影響。
初始進化階段，為了保持種群的多樣性，便于從中進行選擇，應該加大對于個體間相互交叉和互換的概率；在進化的終極階段，頻繁的交叉互換不利于種群的穩定和最優解的產生，因此需要適當地減小個體間的聯系和活動，減少最優解的求解難度，縮短求解過程。針對種群中的個體而言，在進行變異操作時，對優勢個體進行較小的變異，劣勢個體進行較大的變異，可以使其更加趨近于最優解。
（2）合理構造適應值函數
適應值函數可以針對遺傳算法的求解過程進行指導，對最優解的數值區間進行限定，在適應值函數的構造過程中，引入關鍵分支的概念。關鍵分支，指在選定的路徑中，對存在的結點的真實性進行判定，求解過程可能會在這些結點處產生偏離，引發錯誤，而這些會導致求解過程偏離目標路徑的結點，就是關鍵分支。
適應值函數在遺傳算法中是用來區分個體優劣的標準，是進行自然選擇的唯一依據。原始適應值函數是對問題最初求解目標的反映。適應值對個體的判斷有兩個截然相反的情形：適應值越大，個體性能越好和適應值越小，個體性能越好。在遺傳算法中，對適應值函數是有限制的，即適應值函數必須為非負數，這就需要選擇較大的適應值函數來選擇較為優良的個體。
為了使被測數據中每個參數都可以得到評估，根據相關數據對判斷結點進行數據轉換，在保證個體數據得到充分計算的情況下，不會對程序主體造成破壞
3 實驗結果與分析
為了對退火遺傳算法的性能進行驗證，采用判斷三角形的相關測試程序，將退火遺傳算法與單純的遺傳算法進行對比，對進化每一代的最大適應值進行記錄。
從實驗數據可以看出，初始進化階段，個體的產生具有隨機性，在對實驗進行多次運行后，可以看出，最高適應值之間差異十分明顯。進化過程初期，兩種算法的最高適應值都存在較大的波動，而隨著遺傳的不斷進行，退火遺傳算法的最大適應值范圍逐漸趨于穩定，而遺傳算法的最大適應值范圍仍不穩定。因此可以得出結論，將模擬退火算法與遺傳算法相互配合，可以有效避免單一遺傳算法的不足，加快對最優解的計算速度，減少計算所需時間。根據實驗的數據，對多次實驗的結果進行統一總結，可以看出，相對于單一的遺傳算法而言，退火遺傳算法的進化速度大大加快，減少了計算時間。
4 結束語
經過實驗和分析，我們可以看到，生成高代碼覆蓋率的測試用例是自動化測試的關鍵問題，是提高自動化測試性能的主要手段。針對遺傳算法存在的缺陷，將遺傳算法和模擬退火算法相互結合，實現優勢互補，針對群體數據中的遺傳算子以及適應值函數作出改進，最終通過對比實驗，驗證了退火遺傳算法的有效性和優越性。
參考文獻：
[1]趙慧娟，孫文輝.基于退火遺傳算法的單元測試方法[J].計算機工程，2013，39（1）：49-53.
[2]楊學紅.自動化單元測試概述[J].信息通信技術，2012，（1）：66-68.
摘 要:隨著汽車電子市場的快速發展，汽車控制器的電子控制單元(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)的廣泛應用。現如今，車輛上電控單元數量不斷增加，功能越發復雜，多個處理器之間相互連接、協調工作并共享信息構成了汽車車載互聯通信網絡。其中控制器局域網絡(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控制信號。“ECU控制顯示部分”是對接收到的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)。
【關鍵詞】車頂單元；制冷量；設計
上世紀90年代后，隨著鐵路空調客車的飛速的發展，車頂單元式空調器的產量逐年增加。據不完全統計，目前國內擁有空調器約20000多臺。值得注意的是投入運用的空調器早已到了大修期，其中絕大部分為車頂單元式空調器。為保證檢修后的空調器的性能，客車車頂單元式空調器的檢修試驗就顯得十分重要。
一、客車車頂單元式空調器的性能試驗裝置
1、空調器的型號
目前，我國鐵路客車用空調器的主要型式是車頂單元式。該型空調器自1980年從日本引進，仿制改進，至今已經運用20多年，通過不斷地改進完善，現在已經形成標準化，系列化。空調器的結構型式主要有三種：平底側出風口型，代號為“—”；圓底下出風型，代號為“Y”；平底側出風口型，代號為“P”。平底側出風型空調器安裝于客車車頂端部，新造客車安裝的絕大部分都是這種型式。
2、空調器的構造
車頂單元式空調器是將機械制冷部分的壓縮機、冷凝器、干燥過濾器、毛細管(或膨脹閥)、蒸發器、氣液分離器、冷凝風機、蒸發風機和空氣預熱器等集中裝在一個箱體內，組成一個單元，可方便地安裝在車頂部。與空調器配套的電氣控制柜安裝在車內配電室，空調器與電氣控制柜通過電氣連接器(插頭、插座)連接，由發電車集中供電(亦可由本車懸掛式發電機供電)。空調器出風口與車內主風道之間通過軟風道連接，空調器處理后的空氣經車內主風道由送風口送入客室內，達到調節車內空氣溫度的目的。由此可見，客車車頂單元式空調器性能試驗裝置的重要性。
3、設計原則
1）試驗裝置結構力求緊湊，占地面積盡量小，以求適應于各類生產車間的工藝布局；
2）外形應該美觀，設備整體性強；
3）工藝布置應該靈活，工藝設計應該簡單；
4）操作方便，參數的測試及數據處理要求準確
4、設計方案的確定
目前現場使用的車頂單元式空調器性能裝置有閉路式和開路式兩種原理方法：
1）閉路式測試原理方法
該方式需要一間室外側試驗室一間室內試驗室，被試空調器安裝于室外側試驗室內，該室內的空氣溫度需要調節到名義工況下空調器冷凝器進風溫度，經空調器制冷后的空氣由送風道引入置于室內側試驗室的空氣流量測試裝置進行空氣流量測量，接著進入空氣調節裝置，調節后的空氣再由回風道被空調器吸入，即完成了一次循環。空氣 參數調節及空氣流量測量均在風道內進行，該方式的特點是測試環路必須密閉，熱濕損耗較小。
2）開路式測試原理方法
該方式與閉路式的區別在于，空氣經過流量測量裝置后直接排入室內側試驗室內，在房間內進行空氣調節。其優點是室內側試驗室的空氣參數易于穩定，但熱濕損耗較大。
對于這兩種方式，均需要設置獨立的試驗房屋，房屋面積隨實際情況而定。被試空調器的安裝可采用固定式安裝架或試驗小車。如果采用固定式安裝架，則一般采用箱式結構，室外需設置空調器吊裝設備。若采用試驗小車則一般采用房間式結構（即由幾間相互隔熱的房間構成）可在有起重機的檢修間將空調器吊裝到小車上，試驗小車推入室外側試驗室，接上管道即可進行試驗。
相比于房間式結構，箱式結構相對構造簡單，占地面積較小，它的工藝布置也相對靈活，工藝設置簡單，不需要大量的土建工程。所以，本設計“以箱體式空調器試驗裝置”作為總體設計方案。針對箱體式試驗裝置的特點，其室內可以安裝加熱加濕裝置，彌補室內的熱濕損耗，所以我們選用開路式測試原理。綜上所述，我們本次設計方案最后確定為：“箱體結構式的開路式測試”車頂單元式空調器性能裝置
二、制冷量的測量方法設計
1、設計原則
1）測量精度高，范圍寬，系統環節少；
2）測量裝置結構力求緊湊，體積小，以適應在箱體內布局；
3）裝置安裝操作維護應該方便，參數的讀取和數據的處理應該力求簡單方便。
2、測量方案確定
目前，由于某些設計單位設計的試驗裝置僅僅采用一種方法測試制冷量，不能有效地控制室外側空調器的冷凝器的進風溫度，造成試驗工況的不穩定，影響了測試精度。
《客車空調三機檢修及運用管理規程》中規定，空調器制冷量達不到原參數的90％時，應該分解制冷系統。這就要求所建的試驗裝置工況要穩定，測試數據應該準確。TB/T2432-93《鐵道客車車頂單元式空調器試驗方法》中規定，空調器制冷量試驗方法采用室內側空氣焓差法為主測試方法，室外側空氣焓差法為輔測試方法。對于檢修性能試驗裝置也可以只采用室外側空氣焓差法。但是為了保證試驗裝置測試制冷量的的精度及使所測試空調器性能的穩定性，我們采用室內側空氣焓差法為主測試方法，室外側空氣焓差法為輔測試方法測試制冷。兩種方法測試的結果相對偏差不大于6％，若超出6％，則要進行管路損耗修正。它的特點是穩定性好，不受外界因素變化的影響。
3、測量原理方法
所謂室內側空氣焓差法,即在規定工況下通過測得流經空調器室內側空氣焓差及量流量,經過計算獲得有效制冷量的方法。
所謂室外側空氣溫差法,即在規定工況下通過測得流經空調器室外側空氣溫差及重量流量，經過計算獲得有效制冷量的方法。
三、制熱量的測量方法設計
1、設計原則
1）測量精度高，范圍寬，系統環節少；
2）測量裝置結構力求緊湊，體積小，以適應在箱體內布局；
3）裝置安裝操作維護應該方便，參數的讀取和數據的處理應該力求簡單方便。
2、測量方案確定
我國車頂單元式空調器運行在制熱狀態時候一般在冬季，采用的制熱方式一般是直接加熱。當空調吸入的新鮮空氣和室內的回風在空調器加熱室內被混合加熱后，將其直接送入客室內即可，它相對于制冷狀態而言比較簡單，所以我們測試其制熱量時候可只用一種方法——室內空氣焓差法測試即能滿足要求，為了保證熱損失在控制要求的范圍以內，要用輸入電加熱器的瓦數所制得的熱量來驗算（驗算公式為qd=3.41·x，x為輸入電加熱器的瓦數，x可以在試驗裝置控制柜上讀出來），若誤差大于6％則要進行管路損失修正。若需要修正，修正方法為將兩種結果的差值加給室內空氣焓差法計算的制熱量。
結 語
目前車頂單元式空調器在鐵道客車上的運用已經越來越多，但是空調器性能試驗裝置的價格都非常高。因此，空調器的檢修和性能測試的是急需解決的問題，它直接關系鐵道客車運營情況的好壞。車頂單元式空調器性能試驗裝置能得到廣泛的應用，有助于提高客車空調器的性能，從而提高鐵道客車乘坐的舒適度，也就在一定程度上提高了鐵道客車和其它交通工具的競爭力。
參考文獻
[1]王其偉.單元式空調器性能試驗裝置的工況控制[J].鐵道車輛,2008(12)
關鍵詞關鍵詞：軟件工程；軟件質量；單元測試；測試框架；面向對向程序
中圖分類號：TP302 文獻標識碼：A 文章編號文章編號：16727800（2013）008004503
0 引言
隨著現代軟件工程的不斷發展，人們對軟件質量和生產力的要求越來越高。軟件測試技術和框架復用技術作為提高軟件質量和生產力的有效手段，近年來倍受人們的重視。
傳統的“黑盒”、“白盒”測試技術主要應用于面向過程的程序設計中。隨著面向對象技術的發展，這種技術已不能滿足軟件測試的需要。自動化單元測試框架應用于面向對象單元測試中，通過它來實現單元測試自動化。
單元測試是對軟件進行正確性檢驗的測試工作，是軟件設計的最小單位。單元測試的目的主要是發現每個程序模塊內部可能存在的錯誤。程序員的基本職責是單元測試，單元測試能力是程序員基本能力的體現，程序員必須對自己所編寫的代碼認真負責，軟件的質量與程序員的工作效率直接受程序員單元測試能力高低的影響。
單元測試是一項很重要而且必要的工作。在實際工作中，許多程序員并不愿意對自己編寫的代碼進行測試。軟件開發的工作壓力大，大多數程序員們因為沒有時間測試自己的代碼，使程序的代碼質量得不到保證，有些代碼還需重新編寫，程序員根本沒有時間對代碼進行測試。自動化單元測試框架能夠從根本上解決這個問題，它可以使測試工作變得簡單，這樣更有助于程序員進行代碼開發工作。
1 自動化單元測試框架設計目標
自動化單元測試框架的設計應達到以下目標：首先，框架簡單，可以使測試程序的編寫更簡化。框架使用常見的工具設計，測試工作操作簡單；其次，測試框架應能夠使除作者以外的其他程序員進行代碼測試，并能解釋其結果，即將不同程序員的測試結合起來，且不發生相互沖突。最后，測試用例可以復用，可以以現有的測試為起點形成新的測試。
本文將以這些目標為指導，討論如何用以Kent Beck和Ralph Johnson提出的“模式產生體系結構”的方式來設計框架系統。自動化單元測試框架的設計思想是從0開始根據設計問題應用設計模式，一個接一個逐步設計，直至獲得最終合適的系統架構。其中實現部分采用Java語言來實現，并會使用UML圖來表示各種類及類間關系。
2 面向對象自動化單元測試分析
自動化測試定義為：管理與實施各種測試活動，包括開發測試腳本、執行測試腳本，這樣使驗證測試需求更加方便，通過這些腳本實現了自動測試，可以把它稱為自動測量工具。使用這種自動測試工具對增量軟件集成測試提供了巨大的方便，增加了巨大的價值。每一個新的構件可以重用先前開發的測試腳本，即使需求和軟件有變更，作為一個重要的控制機制，自動測試也能夠確保每一次重新構建的穩定性與準確性。
3 面向對象自動化單元測試框架
自動化測試框架實質是一種自動測試工具，單元測試的核心問題是實現測試自動化。一個完整的自動化測試過程通常包括5個測試活動，分別是測試標識、測試設計、測試實現、測試執行與評估。測試用例針對被測試系統的各項功能準確地開發與設計，而且每一個測試用例都要按順序執行這5個測試開發活動，測試開發活動如圖1所示。
圖1 測試活動
測試標識與測試設計這兩個測試活動主要為智力活動，分別標識測試條件和設計測試用例。測試執行與測試比較這兩個活動屬于比較機械的活動，它們的功能分別為：執行測試用例、將測試輸出結果并與期望輸出結果值相比較。前兩個活動決定了測試用例的質量，后兩個活動適合自動化。在單元測試中，測試執行和測試比較這兩個活動要重復多次，測試標識與測試設計通常只執行一次。因此，在單元測試過程中，重復性的活動特別需要自動化執行。
4 自動化單元測試設計與實現
首先構建對象來表達基本概念：Test Case（測試用例），然后將對象發送到測試框架，再由測試框架執行，最后報告測試結果。
采用Command命令模式將一個請求封裝成一個對象，Command模式可以為每一個操作生成一個與之對應的對象，同時能夠給出一個對應的執行方法。這樣可以對多個用戶請求進行排隊，也可以將多個請求記錄到日志，并使用不同的請求對客戶進行參數化。具體實現方法如下：
其中的run（）方法為模式中的執行方法，可以通過繼承來重用該類，為了便于在測試失敗時能夠識別出失敗的測試，每一個Test Case在創建時都要給出與之對應的名稱，這樣即可判斷出失敗的測試。
圖1展示了測試框架組成部分的快照，也展示了應用于TestCase中的標記。
圖1 測試框架組成部分
5 單元測試用例執行流程
在實際測試過程中，構造參數或資源、測試、釋放資源為測試的業務邏輯過程。例如，在測試數據庫的插入、更新、刪除、查詢等操作時，首先要對數據庫進行連接，然后測試，最后釋放連接。這樣，在一個Test Case中有多個測試，需要反復書寫代碼，這增加了測試人員的工作量，不符合設計目標。
建立測試支架即為所有的測試建立一個共同的結構，可以解決以上問題，初始化代碼、測試代碼和釋放資源的代碼均放在測試支架上，每次運行測試代碼之前，首先都運行初始化代碼，最后運行釋放資源代碼。這樣，每一個測試都會和與之對應的支架一起運行，而且測試結果互不影響，每一個結果都不會影響其它的測試結果。這樣便實現了代碼的復用，大大提高了軟件單元測試的工作效率。
以上通過模板方法實現，模板方法的Template Method靜態結構如圖3所示。
其中，setUp方法初始化測試信息，如數據庫的連接，cleanUp方法的功能是測試結束后釋放資源。runTest方法的功能是進行測試業務邏輯。TestCase的方法的功能為進行測試邏輯框架的設計，run為模板方法。在這里，setUp和cleanUp可以被用來重寫，由框架來進行調用。
6 測試結果收集
創建對象TestResult來收集運行的測試結果，實現代碼如下：
UTF使軟件開發者們更愿意接受測試代碼的工作。有種種好處：UIT使測試用例的實現簡單、一致且模塊化；測試實現與執行的特性支持迭代、增量開發；重新運行測試包的便利使高頻率的回歸測試成為可能；同時它還能保證單元測試的持久性。此外，單元測試框架UTF也是可擴展的，例如，利用Decorator模式，可以不斷向UTF添加新的功能；TestResult類也是框架的一個擴展點。客戶能夠自定義它們的TestResult類，例如， HTMLTestResult可將結果上報為一個HTML文檔等。
參考文獻參考文獻：
[1] （美）普雷斯曼.軟件工程：實踐者的研究方法[M].北京：機械工業出版社，2011.
[2] （美）麥格雷戈.面向對象的軟件測試[M].北京：機械工業出版社，2002.
關鍵詞：軟件測試；單元測試；模擬對象
中圖分類號：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.
【關鍵詞】Testbed/Tbrun 軟件單元測試 嵌入式
單元測試是保障軟件質量的重要技術手段，其過程十分復雜，如果不借助輔助工具，僅靠人工處理，則不僅效率低下，工作量巨大，而且可能出現無法解決的問題。因此，利用一套好的單元測試工具幫助測試人員提高工作效率、工作質量是非常必要的。
1 單元測試的定義
單元測試（圖1和圖2）是一個在隔離狀態下測試單個獨立軟件單元的過程，而集成測試（圖3）允許好幾個單元的同時分析，是多單元測試。因此，在單元測試時，需要模擬被測單元與其他模塊之間的交互，開發驅動模塊和樁模塊構建一個可執行的環境。
2 單元測試的要求
單元測試重點要考慮的測試類型有：
2.1 功能測試
根據需求的關鍵成都選取相應單元開展單元測試（建議需求的關鍵程度為關鍵、重要的單元應100%開展單元測試，需求的關鍵程度為一般的單元可以通過代碼審查驗證其功能）。
2.2 覆蓋率測試
根據軟件等級確定覆蓋率測試（見表1）。
3 如何達到充分的覆蓋率測試
3.1 根據對被測程序的期望實現的功能來構造最有可能的功能測試
這些功能從軟件需求說明書或用戶文檔獲得。在加載測試數據的情況下，應該能夠通過測試工具監控源代碼的執行。當實現功能測試的數據用完后，檢查覆蓋率來發現程序中的哪些部分仍然沒有被測到。應該進一步的構造測試數據并進行執行、分析。一直持續到進行功能測試的數據被執行完或者達到所需的測試度量標準。如果測試數據執行完那么進行（3.2）；否則的話（達到測試度量標準的要求）那么任務就完成了。
3.2 檢查測試覆蓋度量指標
如果語句覆蓋率沒有達到完全覆蓋，那么可能是由于某個特殊的用例運行失敗，錯誤退出等造成的。為了將代碼中的每一行都執行到，將程序執行多次通常是必須的。通常功能測試只能覆蓋程序中40%到60%的可執行語句。當語句覆蓋達到完全，每一條語句都被執行時，便可進行（3.3）。
3.3 檢查所有沒有被執行的分支
通常這些分支中的一部分可以通過構造專門的用例實現對它們的測試。找出程序中未執行分支，將分支測試充分實施后再進行（3.4）。
3.4 有些沒有執行到的分支和路徑，是由于相關的測試用例只有在程序執行出錯或者計算出錯的錯誤狀態下才能實現
這些通常是和程序的冗余保護設計相關，這樣的路徑應該完整的保留。一旦不可行測試路徑被去掉，那么源代碼將會更加有效、健壯并且占用更少的空間。
4 Testbed/Tbrun在單元測試中的應用
使用/Tbrun可自動產生軟件測試的驅動、樁模塊，從而節省時間，測試人員可將重點放在設計測試用例上，提高軟件測試效率。使用Testbed/Tbrun的基本方法：
（1）在已集成了開發環境的Testbed中加載被測軟件單元。
（2）創建并設計測試用例。設置輸入變量值。Testbed/Tbrun創建的測試用例，初始默認的輸入變量有時可能不滿足實際執行路徑的要求，也有可能存在當前執行路徑不需要的輸入變量，可將多余的輸入變量刪除掉，輸入變量選擇完成之后，根據希望被測函數執行的路徑，設置各輸入變量的值；設置樁函數。Testbed/Tbrun能夠通過對被測函數的分析自動為被測函數生成樁函數，在樁函數管理界面，選擇需要進行設置的樁函數，分析判斷是否需要設置樁函數的返回值，還是需要通過調用樁函數改變某些全局變量的值；執行測試用例。設置完成輸入變量和樁函數之后，就可以開始執行測試用例了。
（3）查看覆蓋率信息。每成功執行一個測試用例后，Testbed/Trbun都會統計當前測試用例執行的路徑以及相應的覆蓋率，其中“S”表示語句覆蓋率，“B”表示分支覆蓋率，“MCDC”表示MC/DC覆蓋率，即修正條件/判定覆蓋率。
（4）動態覆蓋率報告的保存。動態覆蓋率報告以.c文件為基本單元，包含當前.c文件中所有函數的動態執行情況，建議每執行完成一個函數的單元測試之后，為各被測函數單獨保存動態覆蓋率報告，在該報告中找到被測函數的具體動態執行信息。
在實際應用中，需要注意以下幾個方面：
（1）main函數的測試。Testbed/Tbrun不支持直接對名稱為main的函數進行單元測試，可通過修改main函數的名稱后再進行單元測試，如將main函數名稱修改為testmain等。
（2）指針變量的測試。Testbed/Tbrun不支持直接對指針進行引用的操作，容易跑飛，需要將指針映射到相應的變量，Testbed/Tbrun支持對指針進行映射。
（3）指針指向絕對的內存地址。在頭文件中，代碼可能包含下列風格，用#define來引入絕對內存地址。例如：#define CONGIG_PAGE_1_ADDR 0x418000，然后在函數中直接從絕對地址中寫入和讀出數據。當在一個主機/主機的測試環境中運行這個函數時，內存訪問違反將發生，易出現程序跑飛的現象。
5 結論
相對于完全人工測試，使用Testbed/Tbrun工具測試提高了工作效率、工作質量。因此，Testbed/Tbrun可以較好地支持嵌入式軟件單元測試的開展。
關鍵詞：Testbed/Tbrun；軟件單元測試；嵌入式軟件
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-2374（2013）18-0027-02
嵌入式軟件作為嵌入式系統的重要組成部分，嵌入式軟件質量問題可能會帶來設備的損壞和人員的傷亡，因而用戶對其質量有較高的要求。軟件測試是對軟件質量檢驗的一個非常重要的手段。而軟件測試中動態測試最基礎的測試就是單元測試。如何開展單元測試以及如何提高單元測試的效率是一個值得研究的問題。
1 軟件單元測試的要求及重點
軟件單元測試是對軟件基本組成單元進行測試，測試軟件單元是否正確地實現規定的功能，是否滿足軟件性能和接口要求。并驗證程序與詳細設計說明的一致性。因此在單元測試時，需要模擬被測單元與其他模塊之間的交互，開發驅動模塊和樁模塊兩種輔助模塊，構建一個可執行的環境，驅動模塊用于模擬被測單元的上層模塊，測試執行時由驅動模塊調用被測單元使其運行；樁模塊用于模擬被測單元在執行過程中所調用的模塊。
單元測試重點考慮的測試類型有：（1） 接口測試。接口測試主要檢查實參與形參的數目是否相等、實參與形參的屬性是否匹配、實參與形參的單位是否一致、傳到被調用模塊的實參的屬性是否與形參的屬性匹配、是否把常量當作變量傳遞等內容。（2）功能測試。功能測試主要是對照軟件單元的設計說明，驗證軟件是否完成了所需的功能。（3）重要執行路徑測試。應設計測試用例以發現錯誤的計算、不正確的比較和不正常的控制流向等錯誤。在計算中比較常見的錯誤是：誤解或錯誤處理算術運算的優先次序、混用不同類的操作、計算精度不夠等。另外在控制軟件執行流程的比較操作中比較常見的錯誤有：不同數據類型的比較、不正確的邏輯操作符或不正確的優先次序、因精度不夠使本應相等的數不相等（如浮點數）等。（4）軟件單元的局部數據結構測試。軟件單元的局部數據結構是一個主要的錯誤來源，應設計測試用例來發現不正確的或不一致的數據說明、初始化有錯或沒有賦初值、不正確的變量名、不一致的數據類型、上溢/下溢或引用錯誤等類型的錯誤。（5）錯誤處理路徑測試。一般軟件錯誤處理路徑測試應考慮下面幾種可能的錯誤：對錯誤的描述不易理解、指出的錯誤并不是所遇到的錯誤、出錯時還沒有進行出錯處理就先進行系統干預、錯誤邊界條件的處理不正確、描述錯誤的信息不正確從而不足以確定出錯的原因等。（6）邊界測試。邊界測試是檢測軟件在其輸入/輸出域、過程參數、狀態轉換、功能界限等具有一定范圍的邊界或端點條件下的運行情況，考核軟件的功能或性能在其邊界條件下或邊界的鄰近區域內是否依然滿足設計要求。按照上去要求進行單元測試時，為達到要求的覆蓋條件，還需采取一定的技術手段對測試覆蓋率進行記錄和分析，確保達到相應的覆蓋率指標。采用TBrun單元級測試工具，能自動產生軟件測試驅動、樁模塊，提供友好的輸入輸出人機交互和覆蓋率統計功能，能有效提高單元測試的測試效率。
2 Testbed在單元測試中的應用
使用 Testbed/TBrun的基本方法是：設計測試用例；在Testbed/TBrun中加載被測單元文件，通過Testbed/TBrun對被測軟件進行源程序自動插裝；根據測試用例設定輸入和預期的輸出，執行插裝好的源程序單元；分析輸入數據、預期輸出和實際輸出；得到被測軟件在當前的測試用例執行過程中代碼的覆蓋率。需要注意的是，每執行一個測試用例就需要重新編譯并執行。Testbed/TBrun的覆蓋率統計只具有累加的功能，因此不能查詢每一測試用例執行后的覆蓋率信息。在執行完所有的測試用例后會生成一個總的覆蓋率文件，Testbed/TBrun通過對覆蓋率文件的分析得出軟件單元相應語句的覆蓋情況，根據這些覆蓋情況可以較快確定冗余的測試數據并增補遺漏的測試數據，從而指導新的測試用例設計。在實際應用Testbed單元測試時，需注意以下三個方面：（1）數組和指針類型的變量的輸入。數組可以通過在Testbed/TBrun插裝后的源代碼中插入數組的初始化語句對數組賦值或者在 Testbed/TBrun 環境中對數
組的一部分賦值。因指針不能被直接賦一個地址，所以輸入指針可采用映射的方式來賦值，將指針變量映射成相應的自定義變量，然后對自定義變量賦值。在測試執行的過程中，這個自定義變量的值就是指針的輸入值。（2）被測單元代碼的必要修改。在實際的測試過程中，有的代碼單元不能直接使用Testbed/TBrun直接執行測試。須在分析之前對代碼單元做少量修改。如Testbed/TBrun 插裝源代碼時會生成 main（）函數，因此被測單元中的 main（）函數要改為其他的名稱以避免造成名字沖突；Testbed/TBrun 執行分析時會執行被測單元，因此被測單元中的 while（1）之類的死循環結構要去掉，否則分析將無法結束。（3）模塊測試后顯示最終整體覆蓋率，不能查詢每一測試用例執行后的覆蓋率信息。
3 結語
Testbed有效地支持了測試人員的測試工作，相對于完全人工測試提高了測試效率。該工具仍存在不足，還需在實踐中不斷完善使用方法。
參考文獻
本文就如何運用反饋——矯正手段提高教學目標效果談幾點看法。
一、在課前通過診斷性測試，獲得學生在學習新內容前的知識反饋，為上新課做好準備。
診斷性測試一般安排在新學期或新開課前進行，測試時間一般5～10分鐘，測試應側重于考查學習新課所需要掌握的基本知識和基本技能。例如，在上動物模擬人體手術實驗課前，先測試學生關于無菌技術和無菌原則方面的知識并補償，由此提高他們的學習外科手術的前提能力，最終提高實驗目標。
二、在課前或課后，通過形成性測試了解學生的達標情況，及時查漏補缺。
1、編制形成性測試題，包括課堂測試題和單元測試題，要確保適合各自的特點。
（1）課堂測試題，要適合在課堂教學中進行測試。課堂教學時間一般以二學時為單位，共80分鐘。其中用以進行課堂測試及反饋矯正的時間通常只有5分鐘，故編制此類試題要突出重點，考慮課堂操作的可行性，試題量不能過多。例如，在“復蘇”一章編制的課堂測試題為：①快速診斷心臟驟停的方法；②心肺初期復蘇的abc步驟；③心臟按壓有效的標志是什么；④心肺復蘇有效的指標是什么等。這些題中包括了本章的重要知識點，學生掌握后，在遇到心臟驟停病人時就會懂得如何去診斷和處理，而且試題量適中，便于在課堂上進行測試和矯正。
（2）單元測試題，即教師根據教學的情況，一般按章節劃分為一個教學單元，每學完一個單元后進行一次單元測試，以評價學生的單元達標情況。單元達標測試覆蓋的目標范圍較大，而且每一目標都應有相應的檢測題，測試時間為20～30分鐘，測試內容多時間少，因此編制此類題主張多用選擇題和判斷題，少用填空題、名詞解釋和問答題，以方便學生答題，做到既能檢測目標又不影響課堂授課。此處，通過定期的單元測試，又能促使學生經常系統地進行復習，有利于知識的鞏固和強化。
2、編制平行性測試題，此類試題適用于對矯正生的檢測。
即用以檢測單元測試中的未達標者，在經過補救矯正后是否已達標。編制此類別試題應與單元形成性測試題是同質不同形的，即用不同的試題形式去檢測同一目標。例如，檢測“補鉀原則”這一目標時，如果在單元形成測試中采用選擇形式，則在平行性測試中可采用判斷或填空題的形式進行檢測。
三、反饋——矯正是對經測試反饋的未達標者及時補救矯正，使其達標。
1、課堂反饋矯正。
課堂測試反饋一般采用提問、回答、接力填空等形式，其中最常用的是課堂提問的形式，而課堂提問的形式主要適合于對個別學生，這與目標教學要面向全體學生的宗旨是矛盾的，為了解決這一矛盾，在提問時應使所提問的學生具有代表性和隨機性。所謂代表性是指所提問的學生能代表全班學生中的某一部分，如優生、中等生或差生。要做到有計劃有目的地進行提問檢測，尤其對差生要多進行檢測矯正。隨機性主要是針對課堂教學的具體情況，在全班同學中隨機地進行提問。筆者曾在上“急性闌尾炎”一節時，發現一位同學在上課時開小差，當時立即對她進行提問檢測：“急性闌尾炎最有特征的癥狀是什么？”她回答是“腹痛”。這樣通過提問，可及時地使她調整思維、融入課堂。雖然她答得不全對，但是通過提問既能起到對她及時補救矯正的效果，同時也能引起其他同學的重視（尤其是對提問的這一問題的重視），結果在單元形成測試中全班同學都能答對這一題。這樣通過抓典型、抓代表，達到“牽一發而動全身”的效果，既能及時糾正課堂上出現的個別問題，又能調動全班同學的課堂積極性和主動性，因而能有效地提高教學目標達成度。
市建設經濟運行信息管理系統是建立在j2EE框架基礎上，其BLE(BizLogicHandler)是J2EE框架中的Domain層的實現;BPO(Business Persistence Object)是DAO與BO的結合體，對應J2EE中Persistence層的實現;Web層開發采用Struts框架。涉及各政府職能部門，和下屬鄉鎮政府，轄區大中型企業、重點企業和新招商企業等諸多干系人，需要實現系統查詢、問題反映、信息上報，信息審查，網上辦公，跟蹤督辦，即時通訊，短信提醒，報表打印等主要功能。
對于應用系統的測試，我們劃分為單元測試、部件組合測試、功能測試、性能測試和驗收測試。其中重點關注了單元測試和性能測試，下面分別介紹。
單元測試階段，我們采用開發人員自己寫測試代碼、小組內同級審查和測試組抽查相結合的測試策略。要求單元測試應用緊接在編碼編譯通過之后，鼓勵進行測試先行(即先編寫測試用例，然后用測試驅動代碼的實現)。
單元測試工具采用junit測試框架。因為，我們的開發語言是JAVA，開發工具采用的是MYECLIPSE，而junit是當前JAVA自動化單元測試的實際標準，MYECLIPSE對junit提供了很好的支持。
對Action部分使用StrutesTestCase進行單元測試，StrutsTestCase for Junit是對標準Junit中TestCase的擴展，可以對Strus framework的測試提供方便。我們使用了其中的Mock object方法，測試Action objects、mappings、form beans以及forwords declarations，它不需要servlet引擎及web application container的環境，而且StrutsTestCase提供了許多“validation methods”，方便測試案例編寫。我們采取的原則是，盡可能的把邏輯代碼從jsp/servlet/action中移出，使用Junit作單元測試。該系統單元測試中面臨兩個脫離，脫離BizDelegate(封裝了對Session Fa?ade 的調用過程，降低Application 層與Services層的耦合性)對action進行測試，脫離BPO對BLH進行單元測試，為此我們使用EaseMock技術，為一個接口創建一個模仿對象，將模仿對象作為參數來調用域代碼，具體為測試者提供了抽取方法和工廠方法。
為了保證測試的質量，我們測試之初就設置了專門的測試小組。在單元測試階段，該小組監控所有的測試活動和任務的執行情況，對測試的總體進行跟蹤、控制和報告，對于類的提交，我們制定了嚴格的審核過程。首先，開發人員測試自己的類;然后小組內審查人員審查相應的類，打上已審查標記;最后，測試小組審核和抽查已審查的測試類和代碼;測試小組還需要根據審核和抽查情況進行統計分析，調節測試資源分布。
在性能測試階段，我們分為四個階段實施;啟動階段、準備階段和分析階段。測試工具采用Rational Test Manager 2003，測試環境包括local computer和Test agent，Local computer作為測試平臺的控制主機，負責整個測試的計劃、設計、實現、執行和評估，作為Test agent的機器，統一接收由Local computer，最后由Local computer生成統計報告。在測試中我們也發現響應時間慢的問題，在經過對服務器的調優，以及相應部分的代碼優化、SQL優化之后，性能得到明顯改善。
下面簡單介紹性能測試中我們對遇到的問題所采取的策略：
(1)該系統采用的是J2EE架構的一種模式，GUI客戶端直接和服務器連接，采用的是BEA公司獨有的T3協議，而且前自動化測試工具能夠錄制和回放腳本的大都是基于HTTP協議的瀏覽器客戶端方式。對此，我們采取自動錄制和手工編寫腳本相結合的方式，對于瀏覽器客戶端的測試，采用自動測試工具錄制腳本;對于GUI客戶端的測試，用JAVA配以性能測試工具提供的API包，手動或半手動編寫測試腳本。
(2)該系統業務功能繁多，測試需要準備的數據量大，而測試時間短。我們分析出業務具有代表性的重要和關鍵用例，并且利用開發過程已有的客戶端程序，減少測試腳本的開發量。
(3)該系統渠道多，與外部系統接口復雜，而且系統采用多家公司產品，如果出現問題，分析和定位困難。對此，我們利用性能測試檢驗客戶和系統之間的交互，包括瀏覽器和GUI客戶端等方式的連接。同時在進行性能測試的時候，將內部各種系統，與其連接的各外部系統的日志和監控工具全部打開，記錄各部分的處理過程，這樣當發現性能問題時，便能及時的定位瓶頸出現的位置;測試環境準備和測試時，請相關廠家的工程師提供現場支持，進行性能監控和問題分析。
由于采用了適當的測試方法、測試策略和測試工具，總體來看，我們的測試取得了不錯的效果，有力地保證了項目的質量，XX市經濟運行信息系統現已正式穩定的運行，也受到用戶的好評，這是我們重視軟件開發過程的測試保證軟件質量的結果。當然也有不足的地方，具體存在以下幾個方面;
(1)開發人員的測試觀念還不夠強，雖然我們制定了良好的單元測試策略，但開發人員并沒有很好的執行，以至于在以后階段的測試和運行中受害不淺。
(2)每種測試之前，我們都組織力量充分準備了測試方案，但是在測試數據的準備上，由于系統復雜性等多方面的原因，有些數據準備的不夠完備。
要解決以上問題，我認為首先還是要樹立開發人員的測試理念，只有從具體的開發人員做起，才能整整提高測試的質量，其次還要堅決貫徹執行項目中確立的測試方法和策略。
我們從實踐中領會到，測試確實可以在保證軟件質量方面起到很大的作用。但同時我們也認識到，測試中還有很多領域和知識需要繼續研究和實踐，新技術的發展對測試也提出了新的要求和挑戰，我們將在測試領域不斷探索，不斷創新，為我國電子政務建設和企業信息化建設多做貢獻。
作者：孟曉微 來源：科學與財富 2010年11期
