序論：好文章的創(chuàng)作是一個(gè)不斷探索和完善的過程，我們?yōu)槟扑]十篇單元測(cè)試方法范例，希望它們能助您一臂之力，提升您的閱讀品質(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)行完全的軟件測(cè)試也越來越重要，大多數(shù)軟件開發(fā)者都已意識(shí)到這一點(diǎn)。但考慮到測(cè)試費(fèi)用問題，軟件開發(fā)者往往面臨著在提高產(chǎn)品質(zhì)量與減少費(fèi)用之間進(jìn)行選擇的問題。IPL提供的Cantata測(cè)試軟件應(yīng)這種需要，在合理的費(fèi)用下提供給軟件開發(fā)者的強(qiáng)有效的軟件測(cè)試工具。Cantata可以同時(shí)支持C和C++語(yǔ)言的測(cè)試，能夠滿足開發(fā)者進(jìn)行高效的單元和集成測(cè)試的需求，該產(chǎn)品不僅能提高產(chǎn)品質(zhì)量，還能幫助提高生產(chǎn)率。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

struct DIST* StrCount；

struct FILTER* StrFilter；

在測(cè)試用例腳本中可以通過下面的方式給結(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)存*/

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

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

PORT_CB g_PortCbTable[10]；

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

typedef struct

{

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

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

}PORT_CB；

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

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

4.小結(jié)

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

參考文獻(xiàn)

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

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

篇（2）

關(guān)鍵詞:

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

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

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

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

1 基于CAN總線的ECU功能測(cè)試介紹

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

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

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

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

表1中：Message表示報(bào)文名稱；ID表示報(bào)文仲裁場(chǎng)；DLC表示報(bào)文長(zhǎng)度；Data表示報(bào)文數(shù)據(jù)。

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

2 設(shè)計(jì)方案

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

2.1 方法總體框架

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

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

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

具體測(cè)試方法如下：

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

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

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

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

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

2.2 軟件設(shè)計(jì)流程

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

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

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

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

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

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

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

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

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

3 系統(tǒng)分析

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

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

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

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

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

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

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

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

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

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

V=V參（0.0023P-0.015）

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

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

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

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

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

3.2 待測(cè)ECU模塊

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

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

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

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

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

4 測(cè)試實(shí)現(xiàn)

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

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

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

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

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

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

5 結(jié)語(yǔ)

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

參考文獻(xiàn):

[1]

夏巍，嚴(yán)輝，丁剛.CAN網(wǎng)絡(luò)的實(shí)時(shí)性與可靠性的研究［J］.安徽建筑工業(yè)學(xué)院學(xué)報(bào)：自然科學(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è)儀表與自動(dòng)化裝置,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的汽車測(cè)試方案［J］.汽車制造與裝備,2005(3):44-46.

[6]

程躍,康勁松,徐國(guó)卿.一種車用CAN總線網(wǎng)絡(luò)測(cè)試系統(tǒng)的研究［J］.電子應(yīng)用,2008,27(1):83-86.

[7]

梁銳.NI軟硬件平臺(tái)在汽車ECU開發(fā)和測(cè)試中的應(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ā)動(dòng)機(jī)電控系統(tǒng)實(shí)時(shí)仿真技術(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。

基金項(xiàng)目:

篇（3）

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

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

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

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

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

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

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

1.1.1 載波信號(hào)隔離電路

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

1.1.2 濾波電路

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

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

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

1.1.3 過零檢測(cè)電路

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

1.2 通信主板

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

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

1.2.2 衰減電路

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

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

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

1.2.3 微型處理器MCU控制電路

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

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

1.3 程控上位機(jī)

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

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

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

2 測(cè)試載波通信單元靈敏度步驟

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

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

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

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

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

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

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

3 案例分析

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

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

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

4 結(jié)束語(yǔ)

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

參考文獻(xiàn)

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

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

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

篇（4）

中圖分類號(hào)：G642文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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(cè)試（簡(jiǎn)稱為OO Unit Test）是檢驗(yàn)面向?qū)ο蟪绦蜃钚挝?，即檢查類有無(wú)錯(cuò)誤的測(cè)試工作。因?yàn)轭愂敲嫦驅(qū)ο蟪绦蛑凶罨镜膯挝?，所以?duì)于類的測(cè)試必須要100%通過，這樣面向?qū)ο髥卧獪y(cè)試就顯得非常重要了。面向?qū)ο蟮母拍罴俺绦蛟O(shè)計(jì)方法本身就是一個(gè)難點(diǎn)，那么要幫助學(xué)生理解和掌握面向?qū)ο髥卧獪y(cè)試就更困難了。學(xué)生們對(duì)此也覺得很枯燥，聽不懂，學(xué)不會(huì)，最后放棄了。為了讓學(xué)生掌握這方面的知識(shí)和技能，我采用的方法是以Java類為例，講解面向?qū)ο髥卧獪y(cè)試的基本操作過程，以案例代替概念，理論與實(shí)踐相結(jié)合，采用案例教學(xué)法。

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

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

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

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

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

2 針對(duì)面向?qū)ο笳Z(yǔ)言的特征，選擇自動(dòng)化的單元測(cè)試方法

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

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

1) 面向?qū)ο蟮膯卧獪y(cè)試的對(duì)象是誰(shuí)？

2) 采用人工測(cè)試還是自動(dòng)化測(cè)試？

3) 如果是自動(dòng)化測(cè)試，那么使用什么樣的工具合適？

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

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

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

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

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

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

3.1 選取待測(cè)試的Java類

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

// HelloWorld.java

packageHelloWorld ;

public class helloWorld {

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

returnstr;

}

private String str;

}

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

為了對(duì)HelloWorld類進(jìn)行測(cè)試，我編寫了以下測(cè)試用例，它本身也是一個(gè)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）

中圖分類號(hào)：TP311文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2008)05-00ppp-0c

1 引言

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

2 單元測(cè)試

2.1 什么是單元測(cè)試

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

2.2 單元測(cè)試面對(duì)的難題

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

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

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

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

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

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

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

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

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

3 模擬對(duì)象

3.1 什么是模擬對(duì)象

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

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

3.2 模擬對(duì)象實(shí)現(xiàn)單元測(cè)試應(yīng)用實(shí)例

現(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)在我們想測(cè)試transfer方法，它內(nèi)部調(diào)用的AccountManager的兩個(gè)方法。但是對(duì)于AccountManager來說，它只是個(gè)接口，如下：

public interface AccountManager {

Account findAccountForUser(String userId);

void updateAccount(Account account);

}

所以現(xiàn)在我們必須寫個(gè)MockAccountManager對(duì)象。而且里面的方法體都是非常簡(jiǎn)單的，就是假定它就返回某某值。

我們這里還有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);

}}

這里我們?cè)诩俣ˋccountManager方法都工作正常的情況下，完成了對(duì)transfer方法的測(cè)試。

從以上代碼可以看出，采用Mock Object進(jìn)行的單元測(cè)試基本上可以分為下面幾步：

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

(2)創(chuàng)建Mock Object的一個(gè)對(duì)象

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

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

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

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

3.3 模擬對(duì)象的優(yōu)點(diǎn)

3.3.1 模擬對(duì)象作為測(cè)試手段的優(yōu)點(diǎn)

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

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

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

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

3.3.2 模擬對(duì)象作為設(shè)計(jì)手段的優(yōu)點(diǎn)

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

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

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

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

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

3.4 模擬對(duì)象的局限性

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

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

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

4 結(jié)束語(yǔ)

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

參考文獻(xiàn)：

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

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

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

篇（6）

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

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

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

1 面向程序的單元測(cè)試弊端闡述

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

2 AOP編程闡述

2.1 1AOP編程重要性

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

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

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

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

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

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

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

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

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

3.2 契約的單元測(cè)試

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

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

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

3.3 獨(dú)立單元檢測(cè)

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

4 結(jié)束語(yǔ)

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

參考文獻(xiàn)

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

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

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

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

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

作者簡(jiǎn)介

篇（7）

1 軟件測(cè)試簡(jiǎn)述

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

2 軟件開發(fā)項(xiàng)目測(cè)試的誤區(qū)

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

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

3 嵌入式軟件單元測(cè)試流程

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

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

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

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

4 結(jié)束語(yǔ)

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

參考文獻(xiàn)

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

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

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

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

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

篇（8）

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

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

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

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

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

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

        2、編制平行性測(cè)試題，此類試題適用于對(duì)矯正生的檢測(cè)。 

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

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

        1、課堂反饋矯正。

篇（9）

1.軟件測(cè)試

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

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

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

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

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

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

2.單元測(cè)試

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

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

（1） 模塊接口測(cè)試

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

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

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

（3） 路徑測(cè)試

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

（4） 錯(cuò)誤處理測(cè)試

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

（5） 邊界測(cè)試

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

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

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

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

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

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

篇（10）

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

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

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

二、要注重選題的典型性

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

三、要注重選題的多用度

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

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

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

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

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

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

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