單元測試方法匯總十篇

序論：好文章的創作是一個不斷探索和完善的過程，我們為您推薦十篇單元測試方法范例，希望它們能助您一臂之力，提升您的閱讀品質，帶來更深刻的閱讀感受。

篇（1）

Abstract：The design of unit-testing case is one of the most important part of the unit testing，and it is an important guarantee for improving the software quality to design reasonable unit-testing cases.The article puts forward a designed method of unit-testing cases of a complex function，by introducing the cantata++ which is a testing tool and its function in unit testing，also considering that the true condition of making use of unit testing.This software unit-testing method is widely used in some other tastings and also well reputably.

Key Words：unit testing；cantata++；test case

1.引言

隨著軟件系統越來越復雜，在產品開發各階段進行完全的軟件測試也越來越重要，大多數軟件開發者都已意識到這一點。但考慮到測試費用問題，軟件開發者往往面臨著在提高產品質量與減少費用之間進行選擇的問題。IPL提供的Cantata測試軟件應這種需要，在合理的費用下提供給軟件開發者的強有效的軟件測試工具。Cantata可以同時支持C和C++語言的測試，能夠滿足開發者進行高效的單元和集成測試的需求，該產品不僅能提高產品質量，還能幫助提高生產率。

作為專業軟件測試工具，Cantata++除包含一些標準的特征之外，還提供了一些新功能：

（1）支持語句、判定和布爾代碼覆蓋率度量；

（2）支持運用白盒測試技術，自動獲取私有類數據；

（3）支持面向對象測試用例的重用；

（4）圖形化和XML形式的結果報告。[1]

2.單元測試用例的設計

軟件質量的好壞很大程度上取決于測試用例的設計質量。不論程序員的編程水平、軟件設計水平有多高，軟件工程化執行得多好，如果沒有通過合適質量的測試用例進行測試，其最終軟件質量都是難以保證的。因此，測試用例設計是軟件測試的最核心和最重要的內容之一。[2]

單元測試主要使用白盒測試技術，測試用例的設計方法一般分兩種類型，即測試人員自己編寫測試腳本和借助測試工具生成測試腳本框架后維護測試數據。Cantata++測試工具可用于生成和維護測試腳本，編譯并運行測試可執行程序，查看測試結果和覆蓋率數據。

3.基于cantata的測試用例設計方法

在cantata工具中常見的單元測試用例的實現方法很簡單，不再贅述。本文主要介紹復雜函數實現的單元測試用例的設計方法。如單元測試的被測單元函數使用的函數形參是結構體變量和全局變量是結構體數組且結構體的成員是指針時，在設計測試用例時如何給結構體變量賦值？

3.1 函數的形參為結構體類型

Cantata測試工具自動生成的測試用例中，函數形參的默認值都是“NOT_SET”，編譯測試腳本時不能被識別，給函數的形參賦正確的參數值是得到正確的測試結果的前提。設計帶有結構體類型的形參的測試用例時，我們分別做了如下實驗：

（1）按照在C語言中結構體變量成員賦值的方式給測試用例中的結構體變量賦值；

（2）使用改造C語言結構體變量成員賦值的方式把“->”改為“?”給測試用例中的結構體變量賦值。

編譯結果證明兩種賦值方式均不能被正確識別。

3.2 全局變量為結構體類型的數組變量，且其成員為指針

Cantata在自動生成測試用例時使用其本身封裝的INITIALISE（）函數給全局變量賦初值為0x55，以滿足一般的測試需要。為達到充分測試的目的，需要給全局變量賦相應的數值，當全局變量為結構體類型的數組變量，且其成員為指針時，我們進行了如下實驗：

（1）使用C語言中數組初始化的方式給結構體數組賦值；

（2）一個數組元素一個數據元素的方式給結構體數組賦值；

（3）使用分配內存的方式給結構體數組賦值。

編譯結果證明三種賦值方式均不能被編譯器識別。

結構體形參賦值時是不是因為該形參在賦值之前沒有被分配內存空間所以無法賦值？結構體數組賦值的情況會不會因為cantata測試工具對編碼規則要求較嚴格，必須按照相應的編程規則才可以編譯通過？帶著這種疑問我們查閱了大量編程規則的資料，通過反復實踐，最終找到了解決該兩個問題的辦法。

其一，假設函數形參是如下兩個結構體變量：

struct DIST* StrCount；

struct FILTER* StrFilter；

在測試用例腳本中可以通過下面的方式給結構體變量賦值：

StrCount = malloc（sizeof（struct DIST））；

StrFilter = malloc（sizeof（struct FILTER））；

memset（DIST_COUNT，0，sizeof（struct DIST））；

memset（DIST_FILTER，0，sizeof（struct FILTER））；

StrCount->cnt = 100； /*結構體成員賦初值*/

free（StrCount） ；

free（StrFilter） ；/*釋放內存*/

如此賦值后的測試腳本文件加入測試工程后編譯通過，得到了覆蓋率測試結果，函數形參是結構體類型變量的測試用例設計的問題得以解決。

其二，假定定義如下的結構體數組：

PORT_CB g_PortCbTable[10]；

其中：PORT_CB 為如下的結構體類型：

typedef struct

{

char num[16]； /* 端口名稱*/

CONNOBJ* pObj； /* 端口句柄指針*/

}PORT_CB；

在測試用例腳本中，修改指針成員變量的方式為：

g_PortCbTable[0].pObj = （CONNOBJ*）-1；

g_PortCbTable[1].pObj = （CONNOBJ*）1U；

g_PortCbTable[2].pObj = （CONNOBJ*）1U；

g_PortCbTable[3].pObj = （CONNOBJ*）1U；

g_PortCbTable[4].pObj = （CONNOBJ*）1U；

g_PortCbTable[5].pObj = （CONNOBJ*） -12；

g_PortCbTable[6].pObj = （CONNOBJ*）2U；

g_PortCbTable[7].pObj = （CONNOBJ*）2U；

g_PortCbTable[8].pObj = （CONNOBJ*）2U；

g_PortCbTable[9].pObj = （CONNOBJ*）2U；

其中有后綴U或無后綴指明所賦常量的類型，強制轉換類型不可以忽略。如此賦值后的測試腳本文件加入測試工程后編譯通過，得到了覆蓋率測試結果，至此全局變量為結構體類型的數組變量，且其成員為指針時，測試用例的設計問題得以解決。

4.小結

本文介紹了測試工具cantata的功能特性及其在單元測試中的應用，在此基礎上提出了一種復雜單元函數的測試用例設計方法，該方法在類似的軟件測試項目中得到了應用，在實踐中取得了良好效果。

參考文獻

[1]Cantata++ Reference Manual v6.1 2011，3.

[2]周偉明著.軟件測試實踐[M].電子工業出版社，2008：46.

篇（2）

關鍵詞:

控制器局域網絡；電子控制單元；批量測試；汽車電子；車載網絡

中圖分類號: 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數組和測試表格中都有明確顯示?！癊CU控制顯示部分”顯示出“左前門狀態”燈不亮以及進氣歧管壓力信號數據不一致，這些也同樣說明了信號控制的錯誤。在生成的測試報告(.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。

基金項目:

篇（3）

靈敏度是反應載波通信單元的接收機通信能力的一項重要指標。在同樣的低壓集抄環境中，靈敏度越高的載波通信模塊，抗干擾能力越強、通信距離更遠、通信能力更加可靠。電力部門在采購載波通信單元時，需要通過低壓集抄綜合測試系統測試不同廠家生產的載波通信單元的通信能力，尤其是接收機靈敏度參數。

目前行業內對載波通信單元靈敏度的測試方法相當麻煩、簡單、粗略，通常使用固定值衰減法測試。固定值衰減法測試時，需要不斷跟換不同衰減值的衰減單元，操作不便，且一般衰減值都是10的整數倍，如此一來，只能大概判斷載波通信單元接收靈敏度，無法實現精確測試。

程控衰減法就是研究對電力線載波強電信號進行可上位機程控式衰減的一種方法。它的原理就是首先將220V強電與系統隔離開來，提取出被測的載波信號，然后輸入衰減電路，通過程控上位機可以設置0-120db，步進≥1db（最小單位1db）的信號值衰減，載波信號被衰減后，再耦合至電力線，輸出給載波接收設備。最終通過程控衰減器的具體衰減值以及被測載波接收設備是否正常接收到信號，來計算得載波接收設備的靈敏度。

本文采用的程控衰減法是用來精確測試低壓載波通信單元靈敏度測試的一種方法。

1 程控衰減法的電路實現方法

程控衰減法的電路實現就是實現一種程控衰減器，包括了載波隔離濾波電路和通信主板電路、程控上位機，系統框圖如圖1。

1.1 載波隔離濾波模塊電路組成及作用

1.1.1 載波信號隔離電路

通過串聯諧振的方法，濾除非載波信號，通過耦合變壓器將市電220V與載波通信信號隔離開來，保證整個系統的安全性。

1.1.2 濾波電路

由電阻、電容、電感構成串聯諧振以及并聯諧振，起到濾波作用，當需要某載波頻率f的信號時，則需要計算匹配RLC參數，只有該頻率附近的信號可以通過。計算公式是諧振頻率

（1），品質因數

（2），在滿足其他參數情況下，Q越大越好，通過計算插入損耗值計算電阻R的取值。

1.1.3 過零檢測電路

當檢測到50Hz市電正弦波經過零點時，將判斷信息傳送給MCU處理器。因為載波通信是在市電過零點時發送數據，所以過零檢測也是十分重要的。

1.2 通信主板

1.2.1 穩壓集成電路

為整個系統提供穩定、安全的直流電。

1.2.2 衰減電路

內置各種高精度貼片電阻網絡，分別可以實現1db、2db、4db、8db、10db、20db、30db、40db信號衰減，通過不同的電阻網絡導通組合，可以實現對載波信號進行0-120db衰減，具體電阻網絡組合方式由MCU控制。

0-120db衰減值對應電阻網絡選擇組合方式如表1。

從表2看出，選擇電阻網絡的組合方式，可以直接實現0-115db的信號衰減，載加上程控衰減器其他電路固定衰減值5db，通過正確的組合，就能實現0-120db信號衰減。

1.2.3 微型處理器MCU控制電路

地位相當于“大腦”，它處理上位機發送的信息，實現對衰減電路的控制。

程控衰減法的實現依賴上述電路功能的實現。

1.3 程控上位機

通過鍵盤、鼠標就可以對程控上位機進行各種操作，程控上位機可以直觀設置和顯示衰減值，操作簡便、直觀、人性化。

1.4 程控衰減法測試載波通信單元靈敏度框圖

程控衰減法的實現需要依靠程控衰減器，程控衰減器與載波通信單元的連接如圖3所示。

2 測試載波通信單元靈敏度步驟

以下為使用程控衰減法測試載波通信單元靈敏度的步驟：

第一步：根據已知載波頻率，通過計算公式（1）算得出濾波電路中R、L、C具體匹配參數。

第二步：根據匹配參數，做好對應的載波隔離濾波電路模塊，并且將模塊插入對應的位置中。

第三步：通過程控上位機，設置程控衰減器的衰減值為0db，被測載波發送設備發送符合測試標準的載波信號。

第四步：被測載波接收設備能正常接收載波信號，然后通過上位機不斷加大衰減值步進值為-10db。

第五步：假如現在程控衰減值為-70db時載波接收設備能正常接收信號，程控衰減值為-80db時無法接收信號，那么將衰減值從-79db開始按照步進值1db，不斷減小，直到載波接收設備能正常接收信號為止。

第六步： 假如當程控衰減值等于-75db時，載波接收設備剛好能正常接收數據，那么載波通信單元的接收靈敏度等于-75db加上程控衰減器其他電路的固定衰減值-5db，最終得到載波接收設備靈敏度等于-80db。

3 案例分析

為了充分說明該方法，以421KHz載波頻率的載波通信模塊測試為例。根據相關計算公式（1）計算，得出濾波電路中的R、L、C參數如表3。

使用程控衰減法測試421KHz的載波接收設備靈敏度數據記錄如表4。

表4中的輸出衰減值，可以直接通過程控上位機設置并且顯示出來，觀察表4記錄表，可以得出載波接收設備的靈敏度等于-75db加上電路固定衰減-5db，等于-80db。

4 結束語

要實現對不同載波頻率的載波通信單元接收靈敏度的測試，首先通過計算得出載波隔離濾波模塊電路中RLC匹配參數，通過該電路，濾除非測試頻率的信號。然后通過調節合適的信號衰減值，來確定載波通信單元的靈敏度。本文研究了基于程控衰減法測試載波通信單元靈敏度方法，總結出測試載波通信單元靈敏度的測試步驟。通過對421KHz載波頻率的載波通信單元靈敏度測試分析，精確的測試了該模塊的接收靈敏度等于-80db，驗證了該方法的可操作性和有效性。

參考文獻

[1]高鋒，董亞波，等.低壓電力線載波通信中信號傳輸特性分析[J].電力系統自動化.2000

[2]戚國光.基于OFDM的電力線載波通信系統的研究[D].長沙：湖南大學，7-35.

[3]Zho Wen.110dB Voltage controlled attenuator.JournalofMicrow aves，1993（3）：127

篇（4）

中圖分類號：G642文獻標識碼：A文章編號：1009-3044(2008)35-2435-02

Object-oriented Unit Testing of the Case Teaching Method

ZHENG Li-xiang

(Quanzhou Senior Technical School, Quanzhou 362000, China)

Abstract: This article describes a software testing in the curriculum, students have learned the combination of Java-related knowledge, the case teaching method used to explain the object-oriented unit testing the contents of teaching so that students can understand the theory of knowledge can master the practical skills and to improve their interest in learning to cultivate the ability of students.

Key words: Java class; object-orient unit test; test case

1 引言

面向對象的單元測試（簡稱為OO Unit Test）是檢驗面向對象程序最小單位，即檢查類有無錯誤的測試工作。因為類是面向對象程序中最基本的單位，所以對于類的測試必須要100%通過，這樣面向對象單元測試就顯得非常重要了。面向對象的概念及程序設計方法本身就是一個難點，那么要幫助學生理解和掌握面向對象單元測試就更困難了。學生們對此也覺得很枯燥，聽不懂，學不會，最后放棄了。為了讓學生掌握這方面的知識和技能，我采用的方法是以Java類為例，講解面向對象單元測試的基本操作過程，以案例代替概念，理論與實踐相結合，采用案例教學法。

為什么要采用Java類作為案例進行教學呢？這主要是考慮到以下兩點：

一是Java語言是當前應用前景非常好的軟件設計開發語言，現在的計算機專業一般都會開設這一課程，并且是在《軟件測試》之前開設，學生有知識基礎。

二是Java語言是純面向對象的語言，它摒棄了C/C++中的一些不易掌握的結構，如指針等，其最小處理單位就是類，而且Java語言的程序非常簡潔，理解起來比較容易。

當然作為案例的Java類不能太難了，否則一開始學生就看不懂該Java類的功能，更不用說理解該類的測試過程了。

為了讓學生能夠掌握面向對象單元測試技術，我根據學生的知識水平，選用合適的被測試的Java類，為其設計測試用例，執行測試并生成測試文檔，用完整的案例進行教學。

2 針對面向對象語言的特征，選擇自動化的單元測試方法

在一個典型的軟件項目中，有兩種類型的測試最為重要：程序員測試和用戶測試，或稱為單元測試和驗收測試。單元測試由程序設計師自行編寫測試代碼，目的在于驗證程序設計師所撰寫的代碼是否依據其所設想的方式執行而產生符合預期的結果。即驗證程序代碼的正確性。如果是對采用面向對象方法設計的軟件進行單元測試，就是面向對象單元測試了。

通常，在進行面向對象的單元測試前，我們都要分析幾個問題：

1) 面向對象的單元測試的對象是誰？

2) 采用人工測試還是自動化測試？

3) 如果是自動化測試，那么使用什么樣的工具合適？

4) 如何進行面向對象的單元測試？

對于不同的程序代碼來說，以上的問題可能都有不同的答案與之相對應，那么如果使用的是Java語言所編寫的代碼的話，該怎樣決定呢？

首先，我們知道Java語言是一種高級的、通用的、完全面向對象的程序設計語言，其程序的基本處理單位是類。所以單元測試的對象就是類，即Java的單元測試指的是面向對象的單元測試。

其次，隨著軟件的復雜程度越來越高，面向對象單元測試的工作量也隨之增加了，若采用人工測試恐怕難以完成。因此，自動化的單元測試要比人工測試要來得適用。再者，自動化測試的另一個好處是能生成測試文檔，這樣也可以減少文檔的撰寫工作。

當然，如果選擇了自動化測試就需要工具來支持了，使用何種工具比較合適呢。在此，推薦使用JUnit，這是一種輕量級的測試框架。JUnit是一個開發源代碼的Java測試框架，用于編寫和運行可重復的測試。它是用于單元測試框架體系xUnit的一個實例（用于Java語言）。主要用于白盒測試，回歸測試。JUnit一般不需要另行安裝，通常集成的程序設計平臺，如Eclipse、JBuilder等都會裝有JUnit。

3 設計簡單的Java類的單元測試用例來解析面向對象單元測試

3.1 選取待測試的Java類

為使學生更易理解，案例的選擇要先易后難。我們可以用HelloWorld為例說明JUnit是如何進行單元測試的，因為每一種語言在其學習用書的第一個例子通常都是HelloWorld，它最簡單了。以下是代碼：

// HelloWorld.java

packageHelloWorld ;

public class helloWorld {

public String sayHello( ) {// 返回測試字符串的方法

returnstr;

}

private String str;

}

3.2 設計測試用例，幫助學生掌握測試步驟

為了對HelloWorld類進行測試，我編寫了以下測試用例，它本身也是一個Java類文件。代碼如下：

// HelloWorldTest.java;

package hello.Test ;

import helloWorld.*;

import junit.framework.*;// 引入junit.framework包

public class HelloWorldTest extends TestCase{

//繼承TestCase類

public HelloWorldTest ( String name ) {

super ( name );

}

public static Test suite ( ){

returnnewTestSuite ( HelloWorldTest.class );

}

public static void main ( String args[] ) { //主方法

篇（5）

中圖分類號：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.

篇（6）

單元測試是軟件檢測的主要任務之一，主要分為兩種不同形式：

（1）建立在標準的基礎上，利用黑盒來進行單元測試，來進行測試。

（2）建立在程序主體產生基礎上，利用白盒檢測系統和程序的邏輯性和合理性。

1 面向程序的單元測試弊端闡述

對于單元測試來說，其自身弊端不能忽視。包括文件性質自身弊端OPEN語句錯誤CLOSE語句錯誤，在緩存時，其緩存內存量和記錄長度不符合，正文編寫錯誤等等問題，會對整個系統的板塊和數據帶來影響。其次，測試錯誤處理現象的發生，也會影響描述正確性無法對錯誤定位，對板塊和系統產生干預。

2 AOP編程闡述

2.1 1AOP編程重要性

AOP編程思想是社會發展的產物，是科學技術和社會經濟發展的產物，具有時代性。對AOP編程思想發展背景進行分析和研究，發現AOP編程思想產生于1997年西方國家召開的編程論壇會議上，西方國家的研究人員，在編程會議中給出AOP編程這一理論思想。

單元檢測，也被叫做板塊檢測，其主要服務對象為軟件系統中的最小板塊，針對系統中最小板塊，來判斷程序中板塊的正確性。軟件開發和設計的不斷發展，增加了軟件的種類和復雜性，增加軟件測試的難度，增加單元測試的復雜性。面對這一發展形勢，為了保證軟件開發有效運作，保證軟件的實際應用性，我國開始對軟件測試和開發方法進行深入研究和分析，在長久的研究工作中，發現AOP編程思想具有實際應用，可以滿足軟件開發要求，滿足單元測試發展目標。站在世界角度來說，增加AOP編程思想關注，對整個世界經濟發展具有重要意義。

3 AOP編程思想在面向對象程序的單元測試應用

AOP編程思想在面向對象程序的單元測試應用，包括在對象程序單元測試應用，在契約的單元測試，獨立單元檢測應用。

3.1 AOP編程思想在面向對象程序單元測試步驟

對于AOP編程思想在面向對象程序應用來說，主要是對程序系統進行簡化，簡化為銀行板塊的模式，來對單元進行測試。AOP編程思想在面向對象程序應用主要包括以下幾點內容。

（1）對系統的代碼進行測試，對存在的與消費有關的信息和數據進行反饋，保證不同數據和信息積分反饋的真實性和準確性。詳細來說，系統代碼檢測主要包含三個不同性質的對象，存錢、消費和取錢主體等等。系統代碼可以對著三個不同主體的信息記錄和代碼件反饋。

（2）可以利用賬戶的優勢，利用ID對使用賬戶和新增加的賬戶展開管庫，保證了主體管理的可持續性，保證管理周期最大化。

（3）transfer具有自身的優勢，這一方法可以展現不同賬戶的信息，增加了和賬戶的聯系性，保證服務的完善性。

3.2 契約的單元測試

在對AOP編程思想在面向對象程序單元測試分析后，發現在利用傳統的銀行代碼中，具有自身的便利性，但是也會存在眾多問題。例如：BankAccount這一系統中，運作形式類別簡單和便捷，但是其卻會在應用過程中，出現數據和參數為零的現象，導致不同使用賬戶的財務為負數形式。面對這一發展現象，可以增加契約檢測力度，來避免這一弊端的產生。契約單元測試主要包括以下兩種形式。

（1）利用JAVA系統來運作。1.4系列是JAVA具有代表性的系列，其具有斷言能力，滿足契約檢測的要求。

（2）對契約形式再次構建，保證設計的合理性和構建的科學性。這一構建工作，主要是針對技術來說，對服務主體對象應用技術展開設計，可以保證單元測試的完整性，保證軟件的實際應用性，提高軟件質量。

3.3 獨立單元檢測

獨立單元的檢測和測試具有自身的優勢，降低了單元測試難度。例如：對于獨立單員中存在遺留的代碼來說，運作和替代具有自身難度，利用傳統的檢測方法，無法保證測試的真實性。在面對這一現象，可以利用AOP編程思想優勢，對獨立單元進行隔離處理，把單元換分為幾個系統和板塊，在一一處理，在保證單元獨立性基礎上，增加了對不同板塊信息了解。其次，也可以利用Mocks這一方法展開測試，增加測試主體的協作性，對獨立單元進行劃分，給予隔離層。辯證來說，Mocks這一方法不具有邏輯性，無法滿足邏輯需求。總的來看，AOP編程思想在獨立單元檢測中具有自身的應用優勢，可以對系統中代碼進行修改，和模仿主體的性能類似，利用ID來查找賬戶的信息，并把測試結果展現在系統中。

4 結束語

AOP編程思想是社會發展的產物，具有自身特點，可以利用賬戶的優勢，利用ID對使用賬戶和新增加的賬戶展開管庫，保證主體管理的可持續性，保證了管理周期最大化。

參考文獻

[1]樓程偉，陳麗紅.關于計算機編程思想與AOP編程思想的研究[J].電腦知識與技術，2015（24）：52-53.

[2]謝林.AOP思想在項目中的應用與研究[J].電腦知識與技術，2010（15）：4130-4132.

[3]杜玲玲.AOP技術在國庫集中支付系統的應用[J].計算機應用與軟件，2009（03）：190-191+204.

[4]趙艷，劉同明.面向方面軟件開發在J2EE企業應用系統中的實現[J].計算機技術與發展，2008（10）：225-229.

[5]張永.AOP技術在自助設備運行管理系統中的應用[J].中國金融電腦，2008（08）：91.

作者簡介

篇（7）

1 軟件測試簡述

軟件測試是在軟件投入商用前，對軟件需求分析報告、設計規格說明書和編碼的最終復查，是軟件質量保證的關鍵方法，軟件測試并不等于程序測試。它貫穿于軟件定義和開發的整個過程，因此，軟件需求分析、軟件概要設計、軟件詳細設計和程序編碼等各階段所得到的文檔，包括需求規格說明書、概要設計說明書、詳細設計說明書，以及源代碼都是軟件測試的測試對象。隨著軟件規模的不斷擴大，以及軟件設計復雜程度不斷的提高，軟件開發中出現失誤或缺陷的概率越來越大。隨著市場對軟件質量重要性的認知程序的提高，因此軟件測試在軟件項目實施過程中的重要性尤為突出。軟件測試將會成為一個具有很大發展前景的行業，市場將需要更多具有豐富測試技術和先進管理經驗的測試技術員和項目經理。

2 軟件開發項目測試的誤區

軟件測試從1990年左右進入中國，目前國內大的測評中心、大型企業已經完全掌握了軟件測試的測試策略和測試方法。小企業普遍存在測試人員不懂什么是單元測試，怎樣進行單元測試，很少能看懂代碼的細節。而開發人員很少能夠提供完整的詳細設計報告、需求報告。導致單元測試，以拼湊測試報告為目的。

認知誤區一：軟件測試是軟件開發的最后一道步驟，工程師們一般認為，軟件實際項目要經過下面六個階段：需求分析，概要設計，詳細設計，軟件編碼，軟件測試，軟件。因而，認為軟件測試只是編碼后的一個孤立的階段，這就是不了解軟件測試流程的認知偏差。軟件測試是一個系列的活動過程，是一個開放的體系，包括軟件測試需求分析，測試計劃設計，測試用例設計，執行測試。從而，軟件測試應當貫穿于軟件項目的整個生命周期，并不是軟件開發后最后一道步驟。認知誤區二：軟件商用后如果發現質量問題，就武斷認為是軟件測試人員的工作失誤。這種認識很狹隘，很是打擊軟件測試人員的工作積極性。軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤。因為從根本上講，軟件測試不可能發現全部錯誤，軟件后的錯誤可能來自軟件項目中的各個過程。認知誤區三：軟件測試對測試人員技術要求不高，任何人都可以做。很多工程師認為軟件測試就是安裝并運行程序，按按鍵盤的重復性工作。隨著軟件測試技術的不斷改進和完善，新測試方法、新流程、新工具都在不斷被開發出來。這就需要軟件測試工程師掌握和學習很多專業測試新理念和新技能。認知誤區四：只有編寫程序的高手才是軟件專家，而軟件測試沒有前途。由于我國軟件行業整體研發能力比較低，軟件開發過程不規范。不少軟件項目的開發都還停留在“累加堆疊“階段。項目開發依靠個別程序員決定，他們一人負責總體設計和代碼編寫，給人的印象是程序員是真正的牛人，完成了所有的軟件項目開發工作。但在微軟等世界知名軟件企業里，軟件測試人員的待遇和數量與一般程序員沒有多少差異，優秀測試人員的待遇甚至比普通程序員要高的多。

3 嵌入式軟件單元測試流程

單元測試是指對軟件中的最小可測試單元進行檢查和驗證。單元是規格說明書中的最小單元，包括函數、子程序、程序。單元測試關注獨立的函數功能，是測試過程中最低級別的測試活動。需要開發一個或多個測試用例執行單元測試。把代碼問題縮小范圍在開發階段鎖定Bug是單元測試的主旨要求，以下將介紹一種容易操作的嵌入式單元測試實戰流程。

第一階段，制定測試記錄表，記錄測試過程，和測試情況。測試記錄表包含：源文件名，子函數名，用例標號，用例名稱，用例個數，用例通過個數，語句覆蓋率，分支覆蓋率，MC/DC覆蓋率，測試結果，問題描述，測試人員，測試時間。針對第一階段的測試結果，此時需要大家分析出問題的代碼，各抒己見，總結問題，給出解決方法。

第二階段，解決部分測試用例failed問題，找出阻止生成用例的共性。常見問題匯總：局部變量未初始化，調用函數未聲明，局部變量直接賦值，結構體嵌套、結構體指針、聲明問題、聲明位置問題，函數指針，大循環、死循環，絕對地址，指針變量，C語言程序中帶有goto語句。解決辦法：局部變量聲明后，需要賦初值再使用。調用函數未聲明，該問題發生在隔離測試階段，屬于代碼書寫不規范問題。解決方法：自定義的函數都需要在頭文件中做統一聲明。局部變量直接賦初值：該問題發生在測試用例無法生成階段，屬于代碼書寫不規范問題。解決方法，結構體局部變量，指針變量需要先聲明后賦初值。結構體嵌套、結構體指針、聲明問題、聲明位置問題：該問題也屬于代碼書寫不規范問題。解決方法：根據MISRA代碼書寫規范，結構體需要放在頭文件中統一聲明。大循環、死循環：單元測試需要有程序結束的出口。解決方法：把大循環改為小循環，注釋掉死循環（if（1）、for（； ；），while（1））。絕對地址：單元測試不連接真實的硬件設備。遇到寄存器等絕對地址時，需要對寄存器做變量處理。指針變量：需要聲明一個同類的數組，然后把數組的首地址，賦給指針變量。函數指針：需要虛構一個函數實體，取函數地地址賦給函數指針，完成映射。C語言程序中帶有goto語句：需要改變程序結構，增加判斷語句，去除所有的goto語句，以便確保C語言程序的穩定性。

測試第三階段：基本圈復雜度高于MISRA閥值要求的函數，先考慮把復雜函數改為幾個小函數。改不了的由開發人員寫聲明以及具體原因，再按照路徑分支來設計測試用例。匯總測試結果，提交測試問題報告單，并提交行業標準測試報告。

4 結束語

文章簡述了軟件測試的基本概念，澄清了軟件測試工程實踐中的幾個誤區，依據單元測試實踐的具體案例，介紹了一種高效、容易操作的嵌入式單元測試的流程。

參考文獻

[1]胡丹，杜新華.基于目標機的嵌入式軟件單元測試[J].電子測量技術，2006（2）.

[2]趙正海，王寧.跟蹤雷達“指示引導”功能軟件測試方法研究[J].現代電子技術，2013（36）.

[3]于園園.軟件測試技術與測試管理研究[J].江蘇科技信息，2016（7）.

[4]王琨.嵌入式計算機軟件測試關鍵技術探討[J].科技創新與應用，2016（7）.

[5]張金環，田洪濤.淺析設備軟件測試與質量保證[J].電子工業專用備，2016，45（1）.

篇（8）

一、在課前通過診斷性測試，獲得學生在學習新內容前的知識反饋，為上新課做好準備。

診斷性測試一般安排在新學期或新開課前進行，測試時間一般5～10分鐘，測試應側重于考查學習新課所需要掌握的基本知識和基本技能。例如，在上動物模擬人體手術實驗課前，先測試學生關于無菌技術和無菌原則方面的知識并補償，由此提高他們的學習外科手術的前提能力，最終提高實驗目標。

二、在課前或課后，通過形成性測試了解學生的達標情況，及時查漏補缺。

1、編制形成性測試題，包括課堂測試題和單元測試題，要確保適合各自的特點。

（1）課堂測試題，要適合在課堂教學中進行測試。課堂教學時間一般以二學時為單位，共80分鐘。其中用以進行課堂測試及反饋矯正的時間通常只有5分鐘，故編制此類試題要突出重點，考慮課堂操作的可行性，試題量不能過多。例如，在“復蘇”一章編制的課堂測試題為：①快速診斷心臟驟停的方法；②心肺初期復蘇的ABC步驟；③心臟按壓有效的標志是什么；④心肺復蘇有效的指標是什么等。這些題中包括了本章的重要知識點，學生掌握后，在遇到心臟驟停病人時就會懂得如何去診斷和處理，而且試題量適中，便于在課堂上進行測試和矯正。

（2）單元測試題，即教師根據教學的情況，一般按章節劃分為一個教學單元，每學完一個單元后進行一次單元測試，以評價學生的單元達標情況。單元達標測試覆蓋的目標范圍較大，而且每一目標都應有相應的檢測題，測試時間為20～30分鐘，測試內容多時間少，因此編制此類題主張多用選擇題和判斷題，少用填空題、名詞解釋和問答題，以方便學生答題，做到既能檢測目標又不影響課堂授課。此處，通過定期的單元測試，又能促使學生經常系統地進行復習，有利于知識的鞏固和強化。

2、編制平行性測試題，此類試題適用于對矯正生的檢測。

即用以檢測單元測試中的未達標者，在經過補救矯正后是否已達標。編制此類別試題應與單元形成性測試題是同質不同形的，即用不同的試題形式去檢測同一目標。例如，檢測“補鉀原則”這一目標時，如果在單元形成測試中采用選擇形式，則在平行性測試中可采用判斷或填空題的形式進行檢測。

三、反饋——矯正是對經測試反饋的未達標者及時補救矯正，使其達標。

1、課堂反饋矯正。

篇（9）

1.軟件測試

軟件測試是指利用相關測試工具，按照一定的測試方案和流程對軟件系統的功能和性能進行測試，對可能出現的問題進行分析、評估，發現開發錯誤并跟蹤，以確保所開發的軟件滿足用戶需求。軟件測試是保證軟件質量的主要手段，是根據軟件開發各階段的規則說明和程序內部結構而精心設計的一批測試用例，并利用這些測試用例運行程序以發現軟件是否存在錯誤的過程，軟件測試的范圍應當包括更廣泛些，除了考慮正確性外，還應關心程序的效率、健壯性等因素。

軟件測試過程包含單元測試、集成測試、確認測試和系統測試四個步驟：

（1）單元測試：對每一個程序單元進行獨立測試，檢查各程序模塊是否正確地實現了預定的功能。

（2）集成測試：把已通過測試的模塊組裝起來，對軟件體系構造的正確性進行測試。

（3）確認測試：檢查已完成的軟件系統是否已滿足了需求規格說明中的各項需求，軟件配置是否完全、正確。

（4）系統測試：將經過確認的軟件系統置入實際的運行環境中，與其它系統成份結合在一起進行測試。

2.單元測試

單元測試又稱模塊測試，是以軟件系統設計的最小單位——程序模塊為對象，進行正確性檢驗的測試工作。單元測試常被看作編碼的附屬品，在代碼被開發、編譯調試、審查后，單元測試用例設計便開始了。進行充分的單元測試，是提高軟件質量，降低研發成本的必由之路。幾乎所有的開發人員都會對每一段代碼做一定程度的單元測試。如果一個模塊要完成多項功能，可以將該模塊看成由幾個小程序組成，對每個小程序分別進行單元測試。如果是關鍵模塊，往往還要做性能測試。

單元測試以詳細設計說明書和源程序清單為依據，常采用白盒測試的用例，輔之以黑盒測試的用例，以尋找模塊內部可能存在的錯誤為目的，主要完成模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試等任務。

（1） 模塊接口測試

單元測試開始時，要對通過被測模塊的數據流進行測試。包括調用該模塊的輸入參數的正確性、調用其子模塊時提供參數的正確性、全局變量的定義在各模塊中是否一致等。

（2） 局部數據結構測試

包括數據類型的一致性、變量名、變量賦值、全局數據對模塊影響的正確性等檢驗。

（3） 路徑測試

對基本執行路徑和循環進行測試，查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。

（4） 錯誤處理測試

檢測對錯誤條件的響應是否正確，錯誤描述是否與實際的錯誤是否相符、是否能夠對錯誤定位、是否易于理解等。

（5） 邊界測試

通過設定邊界值檢測數據流、控制流中等于、大于或小于比較值時出錯的可能性。

在面向過程編程時代，單元測試所說的單元一般是指函數，而在面向對象編程時代，單元測試所說的單元一般是指類。以類作為測試單位，測試的復雜度相對較高，所以目前通常采用的辦法是為軟件開發建立對應的測試工程，為每個類建立對應的測試類，為每個函數建立測試函數測試結構化的局部代碼。

3.單元測試用例的設計

測試用例是指對某特定的軟件系統進行測試任務的描述，它體現了測試的方案、方法和技術，包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

測試用例的設計也就是測試需求細化的過程，測試需求分析和測試用例設計是密不可分的，前者是后者的依據，后者是前者的體現。測試用例的設計應與復審相結合，根據相關設計信息設計測試數據，以增大發現錯誤的可能性。

單元測試用例可以選取正確輸入、邊緣數據和錯誤輸入作為測試數據。以系統用戶注冊模塊中出生年、月、日的設置為例，通過等價類劃分法設計測試用例。

篇（10）

在高中英語教學中在對一個單元進行完整教學后,進行一次英語單元測試是必要的。由于一個單元有知識范圍窄、相對涉及面小等因素,所以如何從語言學的角度在一定的范圍內對學生理解和英語語言掌握的程度進行全面測試,需要作出一番認真的思考命題,才能達到應有的效果。同時,一套好的單元測試應該是注重學生的語言能力基礎和語言運用能力的層面上,不僅對它進行檢查測試,更重要的是對學生的基本英語語用技能和綜合運用能力起指導的作用?，F行教材注重學生的口語交際、聽說能力的培養,語言知識在生活中的實際運用,這就要求命題者抓住這一功能,對學生進行語言能力的全面檢測。就英語單元測試如何選題的策略,我在教學中作了一些嘗試,與廣大同仁共勉。

一、注重選擇有代表性的題目

在英語教材中有很多單元,而每個單元又含有若干個知識點,具體包括語言知識(如詞匯、語法、句型等)和文化知識,也包括已知的知識和未知的知識。教材有步驟、有程序地介紹了一些語言和文化知識,潛藏了很多語言信息,但是為了檢測學生在學習相關的知識,能否靈活運用,這就要求命題者在有限的測試題目中容納盡可能多的信息。因此,命題者可以提出若干個預選命題方案,然后借助預測測試的結果,對不同的方案進行多方位在難點、能力考查、實際運用等方面有代表性的題目。一般情況下,代表性的題目包含重點題、典型題及綜合運用題等,它們可以體現在不同的題型中。命題者不能命語言測試建立在難、偏、怪,能難倒學生的難題,一方面挫傷了學生的積極性,另一方面,題目不具有代表性,不能起到考查本單元知識掌握的程度。代表性的題目只有在“抓綱務本”的精神指導下,才能獲得以點帶面、觸類旁通的效果,才能體現出語言測試的特點。

二、要注重選題的典型性

英語教材中的單元教學內容安排是“秩序漸進、循環反復”地不斷操練英語基礎知識的,但是英語對中國學生而言,學習的策略方面各有不同,學生往往會對一些知識存在理解上或應用上存在不同疑惑,所以命題者的選題要能夠讓學生在一定程度上借助于測試的手段觀察、發現、探索和研究其自身語言學習上的差異。比如,當今的中學英語語言測試體系不能體現出學生“說”的能力,所以命題者在選題的過程中,要切合于語用學的實際,參照“任務型”教學活動目標,有意識、有策略地通過單元測試的題型的轉變,將“說”的能力測試融于“聽”的測試中。這樣的單元測試的命題導向就是針對學生之缺,了解學生之愁。此外,命題者要結合教學實際中的學生在平時作業中的“常見病”和“多發病”,選編一些“對癥下藥”的治病題,這也是具有針對性意義的。比如:look for與find的用法的差異性就可以成為測試的內容。

三、要注重選題的多用度

在英語單元測試中的多角度是指在一例的題目中容納多個知識點或能力點的考查,訓練學生運用“一題多思”的思維方式。由于當今的英語教學模式側重于“任務型”和“交際型”的活動,這就要求學生具備能在不同層次、不同形式的情景中,綜合應用語言知識完成語言任務的能力;這也就要求測試題目能體現出不同知識點之間的縱橫聯系,能檢測學生的綜合分析問題和解決問題的能力。也就是說測試題靈活性要起到影響試題區分指數的作用,這也就有利于指導教師將來的授課行為,有利于培養學生的解題思維。比如說,完形填空的空白就顯示了對兩種語言模式(一者是作者表達自己的思想的語言模式,一者是讀者根據自己的理解作出的猜測性語言模式)和一種測試意圖(命題者的測試目的),避免了就題論題的俗套。當然,命題的靈活性的特征要體現在與教材的關聯性上,并不是指“難”、“偏”、“怪”。

四、要注重選題的可信度和準確性

英語單元測試題目的好壞應是建立有可信度和準確的基礎上的語言信息(包括知識和能力)的檢測。它必須達到鞏固知識和培養能力甚至對未來教學活動的目的有針對性。一個單元的知識體系,在語言知識上要學生追求多方位,在學習能力上對學生講究多層次。但是在英語單元測試中,測試題應當有一定的可信度和準確性,不能胡子眉毛一把抓,把握好以一個單元的內容為基礎,對學生進行有的放矢的檢測。

五、要注意選題時側重訓練學生思維能力的培養

要培養學生的自學能力,英語教材中有大量體現了學生思維能力訓練的內容,因而英語單元測試應該體現英語思維檢驗的自主性。

所以英語單元測試也應該體現出英語思維的策略性。試題中一定程度地突出解題方法的訓練可以培養學生的綜合測試的能力。這些測試題目的選擇,能夠培養學生獨立思考問題及解決問題的能力,從而避免學生在題海的幻覺中去摸索所謂的方法,使學生的思維形成定勢。

總之,一套科學的單元測試題能夠對學生知識的培養起導向作用,培養學生的英語知識運用能力,培養學生的學習思維方式,提高學生的學習效率,擴充學生的知識。