序論：好文章的創(chuàng)作是一個不斷探索和完善的過程，我們?yōu)槟扑]十篇單元測試方法范例，希望它們能助您一臂之力，提升您的閱讀品質(zhì)，帶來更深刻的閱讀感受。

篇（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.引言

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

作為專業(yè)軟件測試工具，Cantata++除包含一些標(biāo)準(zhǔn)的特征之外，還提供了一些新功能：

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

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

（3）支持面向?qū)ο鬁y試用例的重用；

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

2.單元測試用例的設(shè)計

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

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

3.基于cantata的測試用例設(shè)計方法

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

3.1 函數(shù)的形參為結(jié)構(gòu)體類型

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

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

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

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

3.2 全局變量為結(jié)構(gòu)體類型的數(shù)組變量，且其成員為指針

Cantata在自動生成測試用例時使用其本身封裝的INITIALISE（）函數(shù)給全局變量賦初值為0x55，以滿足一般的測試需要。為達(dá)到充分測試的目的，需要給全局變量賦相應(yīng)的數(shù)值，當(dāng)全局變量為結(jié)構(gòu)體類型的數(shù)組變量，且其成員為指針時，我們進(jìn)行了如下實驗：

（1）使用C語言中數(shù)組初始化的方式給結(jié)構(gòu)體數(shù)組賦值；

（2）一個數(shù)組元素一個數(shù)據(jù)元素的方式給結(jié)構(gòu)體數(shù)組賦值；

（3）使用分配內(nèi)存的方式給結(jié)構(gòu)體數(shù)組賦值。

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

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

其一，假設(shè)函數(shù)形參是如下兩個結(jié)構(gòu)體變量：

struct DIST* StrCount；

struct FILTER* StrFilter；

在測試用例腳本中可以通過下面的方式給結(jié)構(gòu)體變量賦值：

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； /*結(jié)構(gòu)體成員賦初值*/

free（StrCount） ；

free（StrFilter） ；/*釋放內(nèi)存*/

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

其二，假定定義如下的結(jié)構(gòu)體數(shù)組：

PORT_CB g_PortCbTable[10]；

其中：PORT_CB 為如下的結(jié)構(gòu)體類型：

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或無后綴指明所賦常量的類型，強(qiáng)制轉(zhuǎn)換類型不可以忽略。如此賦值后的測試腳本文件加入測試工程后編譯通過，得到了覆蓋率測試結(jié)果，至此全局變量為結(jié)構(gòu)體類型的數(shù)組變量，且其成員為指針時，測試用例的設(shè)計問題得以解決。

4.小結(jié)

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

參考文獻(xiàn)

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

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

篇（2）

關(guān)鍵詞:

控制器局域網(wǎng)絡(luò)；電子控制單元；批量測試；汽車電子；車載網(wǎng)絡(luò)

中圖分類號: TP206.1 文獻(xiàn)標(biāo)志碼: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 引言

隨著汽車電子的不斷發(fā)展，汽車已進(jìn)入電子控制時代，其標(biāo)志為電子控制單元(Electric Control Unit, ECU)的廣泛應(yīng)用?，F(xiàn)如今，車輛上電控單元數(shù)量不斷增加，功能越發(fā)復(fù)雜，多個處理器之間相互連接、協(xié)調(diào)工作并共享信息構(gòu)成了汽車車載互聯(lián)通信網(wǎng)絡(luò)。其中控制器局域網(wǎng)絡(luò)(Controller Area Network, CAN)是汽車中應(yīng)用較多的現(xiàn)場總線。其良好的實時性、可靠性和經(jīng)濟(jì)性能很好地滿足汽車ECU之間數(shù)據(jù)通信的需要，已成為最有發(fā)展前景的現(xiàn)場總線之一［1-2］。因此，帶CAN總線功能的ECU測試也將變得更加復(fù)雜。ECU功能測試屬應(yīng)用層功能測試范疇，是為了檢測ECU是否符合給定的協(xié)議規(guī)范，能否進(jìn)行正常的控制工作。這種測試在系統(tǒng)級開發(fā)中占據(jù)了很大的比重，成為應(yīng)用層測試中最為關(guān)鍵的部分［3］。

在傳統(tǒng)的ECU功能測試中，一種方式是利用測試面板產(chǎn)生ECU各種信號后連接到ECU各輸入引腳，觸發(fā)它的各驅(qū)動模塊進(jìn)行控制工作，有專門的線路負(fù)責(zé)數(shù)據(jù)交換，但這樣的測試系統(tǒng)隨著傳感器數(shù)量的增多，連線非常困難，且需要高速的數(shù)據(jù)采集和信號調(diào)理設(shè)備，使整體成本增加［4-5］；另一種則改進(jìn)了信號的產(chǎn)生方式，即通過虛擬儀器模擬ECU的控制信號來代替?zhèn)鹘y(tǒng)的觸發(fā)信號，采用人工對控制效果進(jìn)行直接的觀察和記錄。這些測試方法都加大了測試過程中的測試誤差、復(fù)雜度和測試工作量，且無法進(jìn)行自動測試和結(jié)果的自動生成，也不能同時對多個ECU進(jìn)行測試，給ECU廠商進(jìn)行批量生產(chǎn)時帶來很大的不便。

由此，引發(fā)了對新的測試方法的思考和探索。基于CAN總線的ECU功能測試方法以CAN總線的傳輸作為關(guān)鍵技術(shù)，采用閉環(huán)測試方法對同型號的ECU進(jìn)行自動和批量測試。

1 基于CAN總線的ECU功能測試介紹

車載控制系統(tǒng)主要任務(wù)就是要解決車身電器設(shè)備的功能性問題，所以，首先應(yīng)關(guān)注ECU是否能實現(xiàn)功能上的控制，即測試其是否滿足控制協(xié)議的要求。ECU在控制功能上包括了通信服務(wù)功能、傳送數(shù)據(jù)功能、診斷信息及標(biāo)定信息功能、設(shè)備監(jiān)控和網(wǎng)絡(luò)管理功能等，具體的要求規(guī)范則由各ECU生產(chǎn)廠商自行制定。

目前應(yīng)用層協(xié)議制定分為以測試為重心的模式和以設(shè)計為重心的模式。不論哪種模式，控制器開發(fā)過程中，都需要通過測試來驗證功能的正確性，確定ECU工作正常并不干擾總線正常通信［6］。

由圖1的控制器開發(fā)“V”模式圖可見，控制器開發(fā)過程包括多個環(huán)節(jié)，其中的應(yīng)用層功能測試是其重要組成部分，它包括ECU功能測試、網(wǎng)絡(luò)管理功能測試、故障診斷測試等，是進(jìn)行實車測試前的重要環(huán)節(jié)。在引入CAN總線后，將大大降低ECU功能測試的復(fù)雜度和測試工作量，是CAN總線測試的重要組成部分［7］。

在基于CAN總線的ECU測試系統(tǒng)中，通信網(wǎng)絡(luò)是進(jìn)行數(shù)據(jù)傳輸，實現(xiàn)各模塊協(xié)調(diào)工作的橋梁［8］。利用LabVIEW［5,7,11］虛擬儀器產(chǎn)生仿真信號代替數(shù)據(jù)采集卡采集的真實信號，并在此基礎(chǔ)上引入CAN總線作為測試的關(guān)鍵技術(shù)，充分發(fā)揮CAN總線在傳輸上的高可靠性和實時性等優(yōu)點。通過總線對仿真信號的測試報文進(jìn)行有效傳輸，如表1所示。

表1中：Message表示報文名稱；ID表示報文仲裁場；DLC表示報文長度；Data表示報文數(shù)據(jù)。

將報文與同型號ECU進(jìn)行連接，形成閉環(huán)測試結(jié)構(gòu)，模擬實車中ECU的各種傳感器信號來驅(qū)動其進(jìn)行控制工作（于3.2節(jié)詳細(xì)描述），將仿真報文數(shù)據(jù)和CAN總線上反饋回來的ECU控制報文數(shù)據(jù)進(jìn)行解析，提取出Data的值，并自動進(jìn)行多次對比和測試后，在人機(jī)界面上對測試結(jié)果和各種信號量進(jìn)行直觀顯示，并利用測試結(jié)果自動生成測試報告，優(yōu)化和改進(jìn)了傳統(tǒng)的測試方法。

2 設(shè)計方案

此方法采用仿真信號序列代替采集卡采集的真實信號，利用CAN總線的特點對數(shù)據(jù)進(jìn)行傳輸，并將整個測試構(gòu)建成閉環(huán)結(jié)構(gòu)，大大降低測試的復(fù)雜性。

2.1 方法總體框架

由CAN2.0協(xié)議可知，CAN報文的基本要素是報文ID、周期和信號與消息的映射關(guān)系。因此對ECU的協(xié)議功能測試，主要任務(wù)就是測試ID、消息周期、確定信號與消息的映射關(guān)系是否滿足要求，并測試在循環(huán)執(zhí)行多次之后，ECU是否具備在控制功能上的穩(wěn)定性［8］。

選用以LabVIEW為軟件平臺實現(xiàn)ECU的功能測試。測試系統(tǒng)整體框架包括三部分：上位機(jī)仿真和測試、CAN網(wǎng)絡(luò)和底層待測ECU模塊。如圖2所示。

工業(yè)計算機(jī)仿真給定ECU的各種信號量，驅(qū)動ECU進(jìn)行控制工作。由于各ECU之間是相互獨立的，“測試與結(jié)果顯示模塊”采集不同ECU廣播的控制信息，并通過ID對它們進(jìn)行識別。對采集到的控制信息進(jìn)行分析、對比原始輸入來判定各個ECU在功能控制中是否滿足協(xié)議要求。

具體測試方法如下：

首先，通過上位機(jī)LabVIEW模擬仿真信號（如：轉(zhuǎn)向燈信號、溫度信號等）,通過NI 6259板卡，與待測ECU各引腳進(jìn)行對接；

然后，發(fā)送仿真信號，驅(qū)動ECU進(jìn)行控制工作，并發(fā)送出相應(yīng)的CAN控制信息；

再次，通過NI 8473s板卡與上位機(jī)LabVIEW進(jìn)行對接，接收采集到的CAN報文，并通過LabVIEW實現(xiàn)報文的解析、處理和ECU控制效果的同步顯示；

最后，把原始仿真數(shù)據(jù)和處理后的數(shù)據(jù)進(jìn)行對比，驗證ECU在功能控制上是否滿足預(yù)期效果，并對以上測試步驟循環(huán)多次，得出測試結(jié)論，生成測試文檔。

在此，根據(jù)測試大綱要求，選用一個由實驗室和整車廠聯(lián)合開發(fā)的ECU作為應(yīng)用實例，仿真信號由模擬信號和開關(guān)量信號組成，主要分為：轉(zhuǎn)向燈信號、報警信號、狀態(tài)信號、門信號、溫度信號和壓力信號控制信號。具體的控制量與變化范圍因測試ECU功能要求進(jìn)行定制化處理。測試ECU仿真控制信號如表2所示。

2.2 軟件設(shè)計流程

上位機(jī)軟件整體分為7部分：虛擬儀器配置、模擬信號仿真、同步信號顯示、測試結(jié)果顯示、系統(tǒng)數(shù)據(jù)判斷、數(shù)據(jù)處理、測試報告生成。模塊示意圖如圖3所示。

1）虛擬儀器配置。對測試時使用的板卡進(jìn)行初始化配置，設(shè)定參數(shù)和使用通道。

2）模擬信號仿真。產(chǎn)生ECU仿真信號（如轉(zhuǎn)向燈信號，水溫信號等）。

3）同步信號顯示。將采集到的CAN報文，進(jìn)行處理之后，在人機(jī)界面上進(jìn)行控件顯示，方便測試者進(jìn)行直接觀察和分析。

4）測試結(jié)果顯示。在人機(jī)界面上進(jìn)行測試結(jié)果的顯示，以表格和BOOL數(shù)組的形式顯示出每個信號在多次測試之后的通過情況。

5）系統(tǒng)數(shù)據(jù)判斷。將處理后的CAN報文數(shù)據(jù)與預(yù)先保存的仿真信號數(shù)據(jù)進(jìn)行對比，得出測試結(jié)果。

6）數(shù)據(jù)處理。處理NI 8473s板卡采集到的CAN報文，提取數(shù)據(jù)信息。

7）測試報告生成。在人機(jī)界面上顯示測試結(jié)果后，將測試結(jié)果以網(wǎng)頁（.html）格式的文檔進(jìn)行保存，便于后期的分析和處理。

軟件設(shè)計流程如圖4所示。

3 系統(tǒng)分析

由圖2測試方法總體框架圖可知，此系統(tǒng)主要包含三部分：上位機(jī)仿真和測試、CAN網(wǎng)絡(luò)和底層待測ECU模塊。其中上位機(jī)仿真和測試模塊又分為仿真信號產(chǎn)生模塊和測試與結(jié)果顯示模塊兩部分。

3.1 仿真信號產(chǎn)生模塊

使用NI 6259板卡和上位機(jī)LabVIEW構(gòu)建仿真信號產(chǎn)生模塊。此板卡可支持48路數(shù)字信號輸出和4路模擬信號輸出。在調(diào)用接口函數(shù)模塊后，可產(chǎn)生需要的仿真信號，在板卡對應(yīng)引腳輸出對應(yīng)電壓信號。

由表2的ECU控制信號表可知，此待測ECU具有兩種不同類型的信號：模擬信號和開關(guān)量信號。所以需要在LabVIEW中使用DAQmx各模塊仿真出ECU需要的模擬信號和開關(guān)量信號。

1）產(chǎn)生模擬仿真信號［10］。需要把模擬信號轉(zhuǎn)化為ECU能識別的電壓信號，一般范圍在5V以內(nèi)。

如：仿真發(fā)動機(jī)冷卻水溫度信號，水溫與電壓之間的關(guān)系如圖5所示。

通過最小二乘法線性擬合得出公式：

y=－4×10－10x5+7×10－8x4－3×10－6x3+0.0002x2－0.0642x+4.2044

其中：y為輸出電壓值；x為冷卻水溫度值。

如：進(jìn)氣歧管壓力信號，壓力與電壓之間的關(guān)系式：

V=V參（0.0023P-0.015）

其中：P為上位機(jī)模擬的壓力值；V參為參考電壓5V。關(guān)系如圖6如示。

由圖5~6可知模擬信號與電壓值之間的轉(zhuǎn)換特性，由上位機(jī)進(jìn)行轉(zhuǎn)換后通過板卡進(jìn)行輸出，傳遞對應(yīng)電壓值到待測ECU,驅(qū)動其進(jìn)行控制工作。

2）產(chǎn)生開關(guān)量仿真信號。

在LabVIEW中定義各種開關(guān)量信號，通過板卡產(chǎn)生高/低電平。一般情況下，ECU檢測到高邊信號（ECU有效電平分兩種：H、L，即高電平有效或低電平有效）后進(jìn)行控制工作（一般情況下，ECU的高電平判斷電壓在2.5V~5V），控制信號的開啟或關(guān)閉，并同步使用CAN模塊廣播CAN報文。

如：DriverDoorStatus（左前門狀態(tài)）,根據(jù)ECU手冊可知，其為BOOL量，所以在前面板中放置一個BOOL型控件。在對信號進(jìn)行操作處理后調(diào)用NI6259板卡的接口函數(shù)并配置通道信息，與此板卡進(jìn)行通信，產(chǎn)生所需仿真信號（此功能是否正?？赏ㄟ^示波器進(jìn)行驗證）。

3.2 待測ECU模塊

車載ECU控制功能工作原理：ECU外接12V工作電壓，在人為進(jìn)行操作或發(fā)生狀態(tài)變化（如開啟轉(zhuǎn)向燈、水溫變化）時電路接通，然后產(chǎn)生電壓值傳遞到ECU的模擬輸入引腳，如圖7所示。

此系統(tǒng)使用板卡產(chǎn)生的各種電壓信號代替左側(cè)虛線部分圖中未見虛線，請補(bǔ)充或說明。，ECU檢測到信號后進(jìn)行控制工作。

3.3 測試與結(jié)果顯示模塊

上位機(jī)LabVIEW調(diào)用NI 8473s板卡接口函數(shù)采集CAN報文［12］。根據(jù)ECU控制協(xié)議，對CAN報文進(jìn)行解析、分析、處理，提取出周期、ID、DATA等控制信息。然后對比原始數(shù)據(jù)（3.1節(jié)部分），進(jìn)行多次測試后，如果每次測試都全部通過，則判斷為Pass，否則為False，并在前面板中進(jìn)行顯示。

其中：原始數(shù)據(jù)包括報文周期、ID和控制信號數(shù)據(jù)等；報文周期和ID由ECU控制協(xié)議決定；控制信號數(shù)據(jù)由仿真控制信號模塊在產(chǎn)生仿真信號時提供。

4 測試實現(xiàn)

測試ECU在控制功能上是否滿足給定的協(xié)議和規(guī)范，并測試在循環(huán)測試多次之后，ECU控制功能是否具有較好的穩(wěn)定性。測試系統(tǒng)人機(jī)界面如圖8所示。

“仿真信號控制部分”產(chǎn)生表1的ECU控制信號。“ECU控制顯示部分”是對接收到的CAN報文進(jìn)行解析、處理之后用控件進(jìn)行形象的顯示，并與“仿真信號控制部分”進(jìn)行對比。結(jié)果顯示，在循環(huán)測試100次之后，信號量“左前門狀態(tài)”和“進(jìn)氣歧管壓力信號”控制出錯，在BOOL數(shù)組和測試表格中都有明確顯示。“ECU控制顯示部分”顯示出“左前門狀態(tài)”燈不亮以及進(jìn)氣歧管壓力信號數(shù)據(jù)不一致，這些也同樣說明了信號控制的錯誤。在生成的測試報告(.html格式)中也有明確顯示，如圖9所示。

從測試過程中得知，各個ECU的觸發(fā)電平有可能不一樣，大致在5V~12V。NI 6259板卡的工作電壓需小于10V，所以在需要觸發(fā)電平高于10V的ECU上進(jìn)行測試時，則需要在板卡的輸出端加入一個增壓電路。

同時，為了保證測試的正確性，在使用示波器確認(rèn)仿真部分的輸出電壓無誤后，采用車載網(wǎng)絡(luò)測試專用工具CANoe對ECU控制報文進(jìn)行監(jiān)測，觀察結(jié)果如圖10如示。

由圖8和圖10可知，使用CANoe監(jiān)測的總線報文與測試系統(tǒng)監(jiān)測到的報文一致，驗證了本文所設(shè)計測試方法的可行性和準(zhǔn)確性。在對比分析圖8和圖10中的監(jiān)測數(shù)據(jù)，驗證了數(shù)據(jù)一致性和通信協(xié)議的可行性。

根據(jù)不同ECU的控制協(xié)議，制定不同的仿真信號產(chǎn)生模塊和測試模塊，并在使用過程中，不斷完善ECU的測試用例庫，在完善后進(jìn)行不同ECU功能測試時，進(jìn)行規(guī)格選擇后，即可實現(xiàn)對不同ECU的功能測試。

5 結(jié)語

本文介紹了ECU功能測試的現(xiàn)狀，優(yōu)化和改進(jìn)了傳統(tǒng)測試方法。此方法以仿真信號代替采集的真實信號來驅(qū)動ECU進(jìn)行控制工作，并引入閉環(huán)結(jié)構(gòu)和CAN總線，使測試過程更加簡單和智能化。所測結(jié)果準(zhǔn)確可靠，能運用于ECU生產(chǎn)線，提高ECU批量測試的工作效率，為整車廠進(jìn)行ECU測試帶來了方便。在完善仿真信號模塊和測試模塊用例庫后可擴(kuò)展到對不同型號ECU的功能測試。同時，此方法的思想，還可以應(yīng)用于車載網(wǎng)絡(luò)的測試、故障診斷等方面，具有較好的理論價值和實際意義。

參考文獻(xiàn):

[1]

夏巍，嚴(yán)輝，丁剛.CAN網(wǎng)絡(luò)的實時性與可靠性的研究［J］.安徽建筑工業(yè)學(xué)院學(xué)報：自然科學(xué)版,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網(wǎng)絡(luò)在汽車控制方法的應(yīng)用［J］.工業(yè)儀表與自動化裝置,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總線網(wǎng)絡(luò)測試系統(tǒng)的研究［J］.電子應(yīng)用,2008,27(1):83-86.

[7]

梁銳.NI軟硬件平臺在汽車ECU開發(fā)和測試中的應(yīng)用［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]

曹更彥.汽車燃?xì)獍l(fā)動機(jī)電控系統(tǒng)實時仿真技術(shù)研究［D］.重慶:重慶郵電大學(xué),2009.

[11]

阮奇楨.我和LabVIEW［M］.北京:北京航空航天大學(xué)出版社,2009.

[12]

Society of Automotive Engineers. SAE J1939 ［EB/OL］. ［2011-03-03］. 省略/PDFs/manual/drehgeber/M36X8/M3658_J1939.pdf.

[13]

胡思德.汽車車載網(wǎng)絡(luò)（VAN/CAN/LIN）技術(shù)詳解［M］.北京：機(jī)械工業(yè)出版社，2006.

收稿日期:2011-06-16;修回日期:2011-08-21。

基金項目:

篇（3）

靈敏度是反應(yīng)載波通信單元的接收機(jī)通信能力的一項重要指標(biāo)。在同樣的低壓集抄環(huán)境中，靈敏度越高的載波通信模塊，抗干擾能力越強(qiáng)、通信距離更遠(yuǎn)、通信能力更加可靠。電力部門在采購載波通信單元時，需要通過低壓集抄綜合測試系統(tǒng)測試不同廠家生產(chǎn)的載波通信單元的通信能力，尤其是接收機(jī)靈敏度參數(shù)。

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

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

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

1 程控衰減法的電路實現(xiàn)方法

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

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

1.1.1 載波信號隔離電路

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

1.1.2 濾波電路

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

（1），品質(zhì)因數(shù)

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

1.1.3 過零檢測電路

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

1.2 通信主板

1.2.1 穩(wěn)壓集成電路

為整個系統(tǒng)提供穩(wěn)定、安全的直流電。

1.2.2 衰減電路

內(nèi)置各種高精度貼片電阻網(wǎng)絡(luò)，分別可以實現(xiàn)1db、2db、4db、8db、10db、20db、30db、40db信號衰減，通過不同的電阻網(wǎng)絡(luò)導(dǎo)通組合，可以實現(xiàn)對載波信號進(jìn)行0-120db衰減，具體電阻網(wǎng)絡(luò)組合方式由MCU控制。

0-120db衰減值對應(yīng)電阻網(wǎng)絡(luò)選擇組合方式如表1。

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

1.2.3 微型處理器MCU控制電路

地位相當(dāng)于“大腦”，它處理上位機(jī)發(fā)送的信息，實現(xiàn)對衰減電路的控制。

程控衰減法的實現(xiàn)依賴上述電路功能的實現(xiàn)。

1.3 程控上位機(jī)

通過鍵盤、鼠標(biāo)就可以對程控上位機(jī)進(jìn)行各種操作，程控上位機(jī)可以直觀設(shè)置和顯示衰減值，操作簡便、直觀、人性化。

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

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

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

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

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

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

第三步：通過程控上位機(jī)，設(shè)置程控衰減器的衰減值為0db，被測載波發(fā)送設(shè)備發(fā)送符合測試標(biāo)準(zhǔn)的載波信號。

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

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

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

3 案例分析

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

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

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

4 結(jié)束語

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

參考文獻(xiàn)

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

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

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

篇（4）

中圖分類號：G642文獻(xiàn)標(biāo)識碼：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 引言

面向?qū)ο蟮膯卧獪y試（簡稱為OO Unit Test）是檢驗面向?qū)ο蟪绦蜃钚挝?，即檢查類有無錯誤的測試工作。因為類是面向?qū)ο蟪绦蛑凶罨镜膯挝?，所以對于類的測試必須要100%通過，這樣面向?qū)ο髥卧獪y試就顯得非常重要了。面向?qū)ο蟮母拍罴俺绦蛟O(shè)計方法本身就是一個難點，那么要幫助學(xué)生理解和掌握面向?qū)ο髥卧獪y試就更困難了。學(xué)生們對此也覺得很枯燥，聽不懂，學(xué)不會，最后放棄了。為了讓學(xué)生掌握這方面的知識和技能，我采用的方法是以Java類為例，講解面向?qū)ο髥卧獪y試的基本操作過程，以案例代替概念，理論與實踐相結(jié)合，采用案例教學(xué)法。

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

一是Java語言是當(dāng)前應(yīng)用前景非常好的軟件設(shè)計開發(fā)語言，現(xiàn)在的計算機(jī)專業(yè)一般都會開設(shè)這一課程，并且是在《軟件測試》之前開設(shè)，學(xué)生有知識基礎(chǔ)。

二是Java語言是純面向?qū)ο蟮恼Z言，它摒棄了C/C++中的一些不易掌握的結(jié)構(gòu)，如指針等，其最小處理單位就是類，而且Java語言的程序非常簡潔，理解起來比較容易。

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

為了讓學(xué)生能夠掌握面向?qū)ο髥卧獪y試技術(shù)，我根據(jù)學(xué)生的知識水平，選用合適的被測試的Java類，為其設(shè)計測試用例，執(zhí)行測試并生成測試文檔，用完整的案例進(jìn)行教學(xué)。

2 針對面向?qū)ο笳Z言的特征，選擇自動化的單元測試方法

在一個典型的軟件項目中，有兩種類型的測試最為重要：程序員測試和用戶測試，或稱為單元測試和驗收測試。單元測試由程序設(shè)計師自行編寫測試代碼，目的在于驗證程序設(shè)計師所撰寫的代碼是否依據(jù)其所設(shè)想的方式執(zhí)行而產(chǎn)生符合預(yù)期的結(jié)果。即驗證程序代碼的正確性。如果是對采用面向?qū)ο蠓椒ㄔO(shè)計的軟件進(jìn)行單元測試，就是面向?qū)ο髥卧獪y試了。

通常，在進(jìn)行面向?qū)ο蟮膯卧獪y試前，我們都要分析幾個問題：

1) 面向?qū)ο蟮膯卧獪y試的對象是誰？

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

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

4) 如何進(jìn)行面向?qū)ο蟮膯卧獪y試？

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

首先，我們知道Java語言是一種高級的、通用的、完全面向?qū)ο蟮某绦蛟O(shè)計語言，其程序的基本處理單位是類。所以單元測試的對象就是類，即Java的單元測試指的是面向?qū)ο蟮膯卧獪y試。

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

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

3 設(shè)計簡單的Java類的單元測試用例來解析面向?qū)ο髥卧獪y試

3.1 選取待測試的Java類

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

// HelloWorld.java

packageHelloWorld ;

public class helloWorld {

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

returnstr;

}

private String str;

}

3.2 設(shè)計測試用例，幫助學(xué)生掌握測試步驟

為了對HelloWorld類進(jìn)行測試，我編寫了以下測試用例，它本身也是一個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文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2008)05-00ppp-0c

1 引言

隨著極限編程在實際軟件開發(fā)項目中的推廣，越來越多的項目開始采用測試驅(qū)動開發(fā)作為主要的軟件開發(fā)方法。單元測試不僅優(yōu)化了軟件系統(tǒng)設(shè)計，還大大簡化了功能測試的工作量[1]。但是另一方面．更多的項目在開始不久就發(fā)現(xiàn)在很多情況下針對一個類編寫單元測試比較困難．隨著項目的進(jìn)行，越來越多的代碼無法進(jìn)行單元測試．到最后整個項目無法繼續(xù)采用測試驅(qū)動的方式進(jìn)行開發(fā)。因此，要將測試驅(qū)動開發(fā)真正在整個項目里貫徹執(zhí)行，必須有一種方法能夠相對容易的解決這些問題。本文將首先討論了單元測試和無法或很難進(jìn)行單元測試的情況，然后引入Mock Object的概念，基于Mock Object實現(xiàn)單元測試。接下來討論在軟件開發(fā)過程中引入Mock Object對測試和設(shè)計的影響。最后簡述了Mock Object的局限性。

2 單元測試

2.1 什么是單元測試

單元測試是對程序中的單個子程序或過程進(jìn)行測試的過程，也就是說，一開始并不是對整個程序進(jìn)行測試，而是將注意力集中在對構(gòu)成程序的較小模塊的測試上面[2]。單元測試從兩個角度進(jìn)行測試：一是測試數(shù)據(jù)都是針對程序的功能來設(shè)計的黑盒測試；二是針對程序的邏輯結(jié)構(gòu)來設(shè)計測試用例的白盒測試。

2.2 單元測試面對的難題

造成針對一個類難以進(jìn)行單元測試的主要原因是因為這個類依賴于一些其它的難以測試的資源。主要有這三類最主要的資源：數(shù)據(jù)庫，第三方組件和網(wǎng)絡(luò)硬件資源。下面我們將對這三大類難以測試的資源進(jìn)行分類討論。

2.2.1 數(shù)據(jù)庫

現(xiàn)在大部分的軟件項目都會采用數(shù)據(jù)庫作為數(shù)據(jù)存儲。常見的開發(fā)團(tuán)隊會在每個開發(fā)人員的機(jī)器上安裝一個本地的數(shù)據(jù)庫，每個人針對自己的數(shù)據(jù)庫進(jìn)行開發(fā)調(diào)試。這樣做的問題是：必須有一種方式同步數(shù)據(jù)庫的設(shè)計。如果有一個人修改了數(shù)據(jù)庫schema或者某個存儲過程，這個修改必須同步到所有開發(fā)者的本地數(shù)據(jù)庫以及測試服務(wù)器上。采用敏捷軟件開發(fā)的很多項目組往往會浪費大量的時間在數(shù)據(jù)庫設(shè)計同步上。更嚴(yán)重的是每周都會遇到由于數(shù)據(jù)庫設(shè)計不同步，修改沖突導(dǎo)致的問題導(dǎo)致整個項目的中心源碼庫在Auto Build時失敗。每個開發(fā)人員都有自己的測試數(shù)據(jù)，除了上面提到的需要把這些測試數(shù)據(jù)同步到所有開發(fā)機(jī)器和測試服務(wù)器上外，還面臨更重大的問題。因為測試用例需要修改數(shù)據(jù)庫，因此還必須準(zhǔn)備一種機(jī)制能夠在每一個測試用例執(zhí)行結(jié)束后重新將所有的測試數(shù)據(jù)調(diào)入數(shù)據(jù)庫。采用最簡單直接的方法就是在每個測試用例執(zhí)行前都將數(shù)據(jù)庫清空，然后再將測試數(shù)據(jù)調(diào)入，這樣會大大減慢單元測試的時間。單元測試時間越長，開發(fā)者就越不愿意執(zhí)行這些測試用例，單元測試所發(fā)揮的作用越小，這也是很多測試驅(qū)動項目最終無法進(jìn)行到底的一個重要原因。另一個非常嚴(yán)重的問題是為了清理測試環(huán)境，在針對商業(yè)邏輯的測試用例中加入了大量的數(shù)據(jù)訪問層的代碼。采用這樣的方式強(qiáng)迫開發(fā)者在開發(fā)商業(yè)邏輯層的同時開發(fā)數(shù)據(jù)訪問層，并且嚴(yán)重降低了可讀性。

2.2.2 第三方組件或應(yīng)用服務(wù)器

數(shù)據(jù)庫是最常見的第三方服務(wù)器。除此以外在越來越多的項目中使用第三方的組件和應(yīng)用服務(wù)器。例如：客戶環(huán)境中的ERP系統(tǒng),全球定位系統(tǒng)(GPS)的Web Service接口，繪圖引擎等。對于這些第三方提供的內(nèi)容，造成難以編寫單元測試的最根本的原因有：一是系統(tǒng)不透明：對于大部分商業(yè)組件或者服務(wù)來說，一個很重要的內(nèi)容是良好的封裝。但這個特性帶來的問題是在外界無法對其內(nèi)部狀態(tài)進(jìn)行控制和訪問。往往經(jīng)過好幾個操作后才能在外部觀察到相應(yīng)的變化。二是環(huán)境配置困難。由于項目組成員計算機(jī)配置不同，加入項目的時間不同，在項目中負(fù)責(zé)的內(nèi)容不同導(dǎo)致無法為所有開發(fā)人員配置一個完全一致的環(huán)境。例如一個繪圖引擎的開發(fā)版的license是按照一個局域網(wǎng)內(nèi)部同時使用的人員個數(shù)收費的，就不可能只為了能夠進(jìn)行完整的單元測試就為只編寫商業(yè)邏輯層的開發(fā)人員也安裝一套。

2.2.3 網(wǎng)絡(luò)資源和硬件資源

在稍大一些的項目中都或多或少的用到一些網(wǎng)絡(luò)資源。例如將文件部署到遠(yuǎn)程的webDAV服務(wù)器上同時很多項目還會用到一些硬件資源。常見的有打印機(jī)、指紋識別驗證或者條形碼閱讀器等。這些資源有兩大特點導(dǎo)致很難針對與他們相關(guān)的類編寫測試用例。

一是資源訪問沖突。很多網(wǎng)絡(luò)資源對于并發(fā)訪問的響應(yīng)協(xié)調(diào)是通過鎖機(jī)制進(jìn)行的，在實際項目中常見的是一個開發(fā)人員在調(diào)試本地代碼時導(dǎo)致遠(yuǎn)端資源被鎖定導(dǎo)致其它開發(fā)者無法訪問這些資源。

二是環(huán)境可控因素。對于網(wǎng)絡(luò)資源和硬件資源相關(guān)代碼的測試與針對商業(yè)邏輯層代碼的測試最大的不同是環(huán)境的不確定性。訪問網(wǎng)絡(luò)資源有可能遇到的異常情況非常多，例如網(wǎng)絡(luò)忙造成訪問超時，也有可能建立鏈接后數(shù)據(jù)傳輸失敗，還有可能數(shù)據(jù)傳輸完成后校驗失敗。針對訪問這些資源的代碼進(jìn)行的測試必須能夠覆蓋到所有可能出現(xiàn)的每一種情況。如果沒有一個可控，并且是全自動的環(huán)境輔助單元測試的話，這項任務(wù)基本上不可能完成。

3 模擬對象

3.1 什么是模擬對象

Mock這個單詞翻譯成中文大概的意思是假的，模擬的。如圖1所示：通過一個常見的對商業(yè)邏輯的測試描述了一個Mock Object。在圖中我們可以看出：測試代碼需要測試商業(yè)邏輯，而商業(yè)邏輯代碼需要通過IMyDataAccess接口訪問底層數(shù)據(jù)庫，這就是數(shù)據(jù)庫依賴問題。為了解決這個問題我們引入一個Mock Object，并將這個Mock Object而非真正的Data Access傳遞給商業(yè)邏輯代碼進(jìn)行測試。這里的Mock Object不需要實現(xiàn)任何邏輯只需要根據(jù)商業(yè)邏輯的需要返回適當(dāng)?shù)膬?nèi)容就可以了。

圖1 使用Mock Object對商業(yè)邏輯進(jìn)行測試

3.2 模擬對象實現(xiàn)單元測試應(yīng)用實例

現(xiàn)在我們寫好了類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);

}}

現(xiàn)在我們想測試transfer方法，它內(nèi)部調(diào)用的AccountManager的兩個方法。但是對于AccountManager來說，它只是個接口，如下：

public interface AccountManager {

Account findAccountForUser(String userId);

void updateAccount(Account account);

}

所以現(xiàn)在我們必須寫個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進(jìn)行的單元測試基本上可以分為下面幾步：

(1)基于一個接口定義Mock并實現(xiàn)這個接口的所有函數(shù)。

(2)創(chuàng)建Mock Object的一個對象

(3)設(shè)置對象內(nèi)部屬性

(4)告訴對象測試代碼希望看到的反應(yīng)

(5)進(jìn)行測試

(6)檢查Mock Object的確按照希望的順序進(jìn)行工作。

3.3 模擬對象的優(yōu)點

3.3.1 模擬對象作為測試手段的優(yōu)點

Mock Object最直接的優(yōu)點在于提供單元測試的質(zhì)量和覆蓋率：

(1)只要在測試中對期待發(fā)生的問題指定好執(zhí)行的順序引入Mock Object對象后的單元測試就是在一個完全可控的環(huán)境里進(jìn)行的。也就是說我們再也不會無法定位一個“時隱時現(xiàn)”的bug。相反我們可以非常迅速的將問題定位在一個類的內(nèi)部，而不是一個函數(shù)調(diào)用序列。

(2)于測試人員來說，最常見的問題是測試人員提交的bug無法在開發(fā)人員那里復(fù)現(xiàn)。有了Mock Object這個工具測試人員可以利用Mock Object明確的指定輸入和輸出編寫一個測試用例讓開發(fā)人員修復(fù)。

(3)超過8O％ 的異常處理代碼沒有被充分測試過。主要原因是在沒有Mock Object之前很多情況是無法由人工進(jìn)行控制的，例如寫文件失敗網(wǎng)絡(luò)連接超時，數(shù)據(jù)庫數(shù)據(jù)傳輸失敗或者從網(wǎng)絡(luò)接收到的數(shù)據(jù)已經(jīng)損壞。通過控制Mock Object我們很容易就可以模擬上面的這些情況。

3.3.2 模擬對象作為設(shè)計手段的優(yōu)點

雖然Mock Object最直接的優(yōu)點在于給予測試代碼更多的可控性和可操作性，它最大的優(yōu)點在于對軟件設(shè)計的影響[3]。

(1)測試驅(qū)動開發(fā)與Mock Object一起使用，可以寫出低耦合高內(nèi)聚，非常優(yōu)雅干凈的代碼。

(2)強(qiáng)迫設(shè)計者放棄對第三方庫的強(qiáng)依賴關(guān)系，取而代之的是比較弱的依賴關(guān)系。

(3)設(shè)計人員可以將更大的注意力放在商業(yè)邏輯的實現(xiàn)和測試．由于Mock Object的存在，我們不需要實現(xiàn)數(shù)據(jù)訪問層就可以對商業(yè)邏輯進(jìn)行測試。而商業(yè)邏輯才是任何系統(tǒng)中對于客戶最重要的內(nèi)容，它的正確與否決定了整個系統(tǒng)是否能完成任務(wù)，它的穩(wěn)定性決定了整個系統(tǒng)架構(gòu)的穩(wěn)定性。

(4)在項目初期，甚至是中期，將設(shè)計人員解放出來，不用對系統(tǒng)底層的基礎(chǔ)設(shè)施做出判斷。例如，在商業(yè)邏輯并不明確，需求還不穩(wěn)定的時候，我們是更多根據(jù)感覺來做出很多重要的判斷的，而這些判斷往往導(dǎo)致比較關(guān)鍵的決定。例如，在項目之初，誰能夠明確的回答到底需要什么樣的數(shù)據(jù)庫？Oracle？SQL Server?還是XML文件？到底需要什么樣的隊列服務(wù)器 MSMQ還是IBM―MQ？由于Mock Object的引入，我們可以將這些決策推遲到商業(yè)邏輯層更加明確之后進(jìn)行，從而可以獲得更加準(zhǔn)確有針對性的答案。

3.4 模擬對象的局限性

Mock Object在實際項目中的應(yīng)用存在一些限制，一些是由于Mock Object本身性質(zhì)決定的，有一些則是由于其它類庫設(shè)計存在的缺陷導(dǎo)致的。

(1)一個典型的不是Mock Object的問題，而是類庫設(shè)計的問題。是Mock Object無法模擬比較深的對象樹。有一些第三方的類庫，尤其是一些消息處理函數(shù)的參數(shù)，提供的不是接口而是一些對象。往往這些對象內(nèi)部有很多子對象，也就是我們常說的一棵大的對象樹。我們需要花費太多的精力去構(gòu)造這些對象來進(jìn)行模擬，時間消耗巨大。

(2)一般性而言，單元測試的粒度越細(xì)，功能測試的粒度就可以越粗[4]。但是引入Mock Object的單元測試仍然無法取代功能測試。一個很好的例子就是誤差積累的測試，哪怕每個單元的誤差都在可接收范圍內(nèi)，我們?nèi)匀恍枰粋€功能測試確保整體誤差也是可以接受的。

4 結(jié)束語

模擬對象解決了傳統(tǒng)單元測試的兩個問題：一是如何將需要測試的代碼與相關(guān)環(huán)境隔離；二是如何創(chuàng)建一個快速、可控的環(huán)境輔助測試開發(fā)。隨著模擬對象技術(shù)的成熟，基于模擬對象的單元測試會越來越廣泛地被采用。

參考文獻(xiàn)：

[1]Kent Beck.測試驅(qū)動開發(fā)[M].北京:中國電力出版社,2003.

[2]Myers.王峰，陳杰譯.軟件測試的藝術(shù)（第二版）[M]. 北京:機(jī)械工業(yè)出版社,2006.50-52.

[3]David Astels.崔凱,譯.測試驅(qū)動開發(fā)實用指南[M].北京:中國電力出版社,2004.120-130.

篇（6）

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

（1）建立在標(biāo)準(zhǔn)的基礎(chǔ)上，利用黑盒來進(jìn)行單元測試，來進(jìn)行測試。

（2）建立在程序主體產(chǎn)生基礎(chǔ)上，利用白盒檢測系統(tǒng)和程序的邏輯性和合理性。

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

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

2 AOP編程闡述

2.1 1AOP編程重要性

AOP編程思想是社會發(fā)展的產(chǎn)物，是科學(xué)技術(shù)和社會經(jīng)濟(jì)發(fā)展的產(chǎn)物，具有時代性。對AOP編程思想發(fā)展背景進(jìn)行分析和研究，發(fā)現(xiàn)AOP編程思想產(chǎn)生于1997年西方國家召開的編程論壇會議上，西方國家的研究人員，在編程會議中給出AOP編程這一理論思想。

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

3 AOP編程思想在面向?qū)ο蟪绦虻膯卧獪y試應(yīng)用

AOP編程思想在面向?qū)ο蟪绦虻膯卧獪y試應(yīng)用，包括在對象程序單元測試應(yīng)用，在契約的單元測試，獨立單元檢測應(yīng)用。

3.1 AOP編程思想在面向?qū)ο蟪绦騿卧獪y試步驟

對于AOP編程思想在面向?qū)ο蟪绦驊?yīng)用來說，主要是對程序系統(tǒng)進(jìn)行簡化，簡化為銀行板塊的模式，來對單元進(jìn)行測試。AOP編程思想在面向?qū)ο蟪绦驊?yīng)用主要包括以下幾點內(nèi)容。

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

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

（3）transfer具有自身的優(yōu)勢，這一方法可以展現(xiàn)不同賬戶的信息，增加了和賬戶的聯(lián)系性，保證服務(wù)的完善性。

3.2 契約的單元測試

在對AOP編程思想在面向?qū)ο蟪绦騿卧獪y試分析后，發(fā)現(xiàn)在利用傳統(tǒng)的銀行代碼中，具有自身的便利性，但是也會存在眾多問題。例如：BankAccount這一系統(tǒng)中，運作形式類別簡單和便捷，但是其卻會在應(yīng)用過程中，出現(xiàn)數(shù)據(jù)和參數(shù)為零的現(xiàn)象，導(dǎo)致不同使用賬戶的財務(wù)為負(fù)數(shù)形式。面對這一發(fā)展現(xiàn)象，可以增加契約檢測力度，來避免這一弊端的產(chǎn)生。契約單元測試主要包括以下兩種形式。

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

（2）對契約形式再次構(gòu)建，保證設(shè)計的合理性和構(gòu)建的科學(xué)性。這一構(gòu)建工作，主要是針對技術(shù)來說，對服務(wù)主體對象應(yīng)用技術(shù)展開設(shè)計，可以保證單元測試的完整性，保證軟件的實際應(yīng)用性，提高軟件質(zhì)量。

3.3 獨立單元檢測

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

4 結(jié)束語

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

參考文獻(xiàn)

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

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

[3]杜玲玲.AOP技術(shù)在國庫集中支付系統(tǒng)的應(yīng)用[J].計算機(jī)應(yīng)用與軟件，2009（03）：190-191+204.

[4]趙艷，劉同明.面向方面軟件開發(fā)在J2EE企業(yè)應(yīng)用系統(tǒng)中的實現(xiàn)[J].計算機(jī)技術(shù)與發(fā)展，2008（10）：225-229.

[5]張永.AOP技術(shù)在自助設(shè)備運行管理系統(tǒng)中的應(yīng)用[J].中國金融電腦，2008（08）：91.

作者簡介

篇（7）

1 軟件測試簡述

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

2 軟件開發(fā)項目測試的誤區(qū)

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

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

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

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

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

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

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

4 結(jié)束語

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

參考文獻(xiàn)

[1]胡丹，杜新華.基于目標(biāo)機(jī)的嵌入式軟件單元測試[J].電子測量技術(shù)，2006（2）.

[2]趙正海，王寧.跟蹤雷達(dá)“指示引導(dǎo)”功能軟件測試方法研究[J].現(xiàn)代電子技術(shù)，2013（36）.

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

[4]王琨.嵌入式計算機(jī)軟件測試關(guān)鍵技術(shù)探討[J].科技創(chuàng)新與應(yīng)用，2016（7）.

[5]張金環(huán)，田洪濤.淺析設(shè)備軟件測試與質(zhì)量保證[J].電子工業(yè)專用備，2016，45（1）.

篇（8）

        一、在課前通過診斷性測試，獲得學(xué)生在學(xué)習(xí)新內(nèi)容前的知識反饋，為上新課做好準(zhǔn)備。

        診斷性測試一般安排在新學(xué)期或新開課前進(jìn)行，測試時間一般5～10分鐘，測試應(yīng)側(cè)重于考查學(xué)習(xí)新課所需要掌握的基本知識和基本技能。例如，在上動物模擬人體手術(shù)實驗課前，先測試學(xué)生關(guān)于無菌技術(shù)和無菌原則方面的知識并補(bǔ)償，由此提高他們的學(xué)習(xí)外科手術(shù)的前提能力，最終提高實驗?zāi)繕?biāo)。

        二、在課前或課后，通過形成性測試了解學(xué)生的達(dá)標(biāo)情況，及時查漏補(bǔ)缺。

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

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

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

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

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

      三、反饋——矯正是對經(jīng)測試反饋的未達(dá)標(biāo)者及時補(bǔ)救矯正，使其達(dá)標(biāo)。

        1、課堂反饋矯正。

篇（9）

1.軟件測試

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

軟件測試過程包含單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試四個步驟：

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

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

（3）確認(rèn)測試：檢查已完成的軟件系統(tǒng)是否已滿足了需求規(guī)格說明中的各項需求，軟件配置是否完全、正確。

（4）系統(tǒng)測試：將經(jīng)過確認(rèn)的軟件系統(tǒng)置入實際的運行環(huán)境中，與其它系統(tǒng)成份結(jié)合在一起進(jìn)行測試。

2.單元測試

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

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

（1） 模塊接口測試

單元測試開始時，要對通過被測模塊的數(shù)據(jù)流進(jìn)行測試。包括調(diào)用該模塊的輸入?yún)?shù)的正確性、調(diào)用其子模塊時提供參數(shù)的正確性、全局變量的定義在各模塊中是否一致等。

（2） 局部數(shù)據(jù)結(jié)構(gòu)測試

包括數(shù)據(jù)類型的一致性、變量名、變量賦值、全局?jǐn)?shù)據(jù)對模塊影響的正確性等檢驗。

（3） 路徑測試

對基本執(zhí)行路徑和循環(huán)進(jìn)行測試，查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。

（4） 錯誤處理測試

檢測對錯誤條件的響應(yīng)是否正確，錯誤描述是否與實際的錯誤是否相符、是否能夠?qū)﹀e誤定位、是否易于理解等。

（5） 邊界測試

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

在面向過程編程時代，單元測試所說的單元一般是指函數(shù)，而在面向?qū)ο缶幊虝r代，單元測試所說的單元一般是指類。以類作為測試單位，測試的復(fù)雜度相對較高，所以目前通常采用的辦法是為軟件開發(fā)建立對應(yīng)的測試工程，為每個類建立對應(yīng)的測試類，為每個函數(shù)建立測試函數(shù)測試結(jié)構(gòu)化的局部代碼。

3.單元測試用例的設(shè)計

測試用例是指對某特定的軟件系統(tǒng)進(jìn)行測試任務(wù)的描述，它體現(xiàn)了測試的方案、方法和技術(shù)，包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。

測試用例的設(shè)計也就是測試需求細(xì)化的過程，測試需求分析和測試用例設(shè)計是密不可分的，前者是后者的依據(jù)，后者是前者的體現(xiàn)。測試用例的設(shè)計應(yīng)與復(fù)審相結(jié)合，根據(jù)相關(guān)設(shè)計信息設(shè)計測試數(shù)據(jù)，以增大發(fā)現(xiàn)錯誤的可能性。

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

篇（10）

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

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

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

二、要注重選題的典型性

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

三、要注重選題的多用度

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

四、要注重選題的可信度和準(zhǔn)確性

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

五、要注意選題時側(cè)重訓(xùn)練學(xué)生思維能力的培養(yǎng)

要培養(yǎng)學(xué)生的自學(xué)能力,英語教材中有大量體現(xiàn)了學(xué)生思維能力訓(xùn)練的內(nèi)容,因而英語單元測試應(yīng)該體現(xiàn)英語思維檢驗的自主性。

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

總之,一套科學(xué)的單元測試題能夠?qū)W(xué)生知識的培養(yǎng)起導(dǎo)向作用,培養(yǎng)學(xué)生的英語知識運用能力,培養(yǎng)學(xué)生的學(xué)習(xí)思維方式,提高學(xué)生的學(xué)習(xí)效率,擴(kuò)充學(xué)生的知識。