時(shí)間：2022-04-26 00:49:09
引言：易發(fā)表網(wǎng)憑借豐富的文秘實(shí)踐，為您精心挑選了九篇單元測試方法范例。如需獲取更多原創(chuàng)內(nèi)容，可隨時(shí)聯(lián)系我們的客服老師。
關(guān)鍵詞：遺傳算法；模擬退火算法；自動(dòng)化；單元測試
中圖分類號(hào)：TP311.53
隨著計(jì)算機(jī)技術(shù)的發(fā)展，計(jì)算機(jī)智能技術(shù)也逐漸得到了開發(fā)應(yīng)用，生物智能、人工智能以及算計(jì)智能的聯(lián)合應(yīng)用和優(yōu)勢互補(bǔ)，使智能技術(shù)的應(yīng)用更加有效。隨著計(jì)算機(jī)的普及，軟件產(chǎn)品已經(jīng)深入人們生活工作的各個(gè)領(lǐng)域，成為日常工作、生活、娛樂的必不可少的組成部分。而對于軟件安全性能的要求則在很大程度上促進(jìn)了軟件測試的發(fā)展。軟件測試是軟件安全性能和良好的使用性能的重要哦保證，貫穿于軟甲開發(fā)過程的始終，保證軟件開發(fā)每個(gè)階段的質(zhì)量。
軟件的質(zhì)量需要經(jīng)過軟件功能測試才能得到保障，而單元測試則是軟件功能測試的基礎(chǔ)和前提，是軟件測試的起步環(huán)節(jié)。單元測試針對的對象是程序中最小的軟件模塊，一般是軟件開發(fā)人員通過編寫小段代碼，針對被測試代碼的某個(gè)較小較明確的功能進(jìn)行測試，看其是否可以正常運(yùn)行。
1 參數(shù)化單元測試
單元測試作為軟件測試的起步環(huán)節(jié)，同時(shí)也是不可或缺的環(huán)節(jié)，對軟件的質(zhì)量起著至關(guān)重要的作用。在實(shí)際測試中，單元測試代碼的手動(dòng)編寫工作是一件極其復(fù)雜且耗時(shí)的工作，并且所選測試實(shí)例不能保證覆蓋較大的代碼，具有很大的隨機(jī)性，進(jìn)而降低單元測試的效率。
參數(shù)化單元測試將程序規(guī)格與測試用例生成分離，解決了傳統(tǒng)單元測試存在的弊端。運(yùn)用參數(shù)化單元測試方法，程序要實(shí)現(xiàn)的功能需要人工書寫代碼，然后測試工具就會(huì)通過對測試代碼的分析和檢測，自動(dòng)根據(jù)測試的實(shí)際路徑生成對應(yīng)的實(shí)例和測試代碼，實(shí)現(xiàn)代碼的高覆蓋率。
2 基于遺傳算法的搜索策略
在退火算法的運(yùn)行過程中溶入遺傳算法，稱為退火遺傳算法，依舊是說，所謂的退火遺傳算法，實(shí)際上是由退火算法和遺傳算法兩個(gè)部分組成，結(jié)合雙方各自的優(yōu)點(diǎn)和特性，所得到的新的綜合性計(jì)算方法。
2.1 遺傳算法依據(jù)
遺傳算法的提出源于計(jì)算機(jī)發(fā)展初期提出的所謂“人工進(jìn)化系統(tǒng)”，它是根據(jù)生物進(jìn)化的特點(diǎn)，借鑒優(yōu)勝劣汰的自然遺傳法則，參照達(dá)爾文進(jìn)化論的理論思想而形成的一種不依賴具體問題的直接搜索方法，在運(yùn)用遺傳算法進(jìn)行數(shù)據(jù)計(jì)算時(shí)，不僅要用到進(jìn)化學(xué)的概念，同時(shí)也要符合遺傳學(xué)說的基因遺傳原理。
運(yùn)用遺傳算法進(jìn)行計(jì)算時(shí)，一般要經(jīng)過幾個(gè)基本步驟，即：初始化數(shù)據(jù)、數(shù)據(jù)的擇優(yōu)選擇、隨機(jī)對選中的兩個(gè)數(shù)據(jù)進(jìn)行交叉互換、根據(jù)遺產(chǎn)學(xué)說的基因變異原理所進(jìn)行的個(gè)體數(shù)據(jù)變異、全局最優(yōu)收斂，進(jìn)而得出需要的結(jié)論或數(shù)據(jù)。
2.2 模擬退火算法依據(jù)
模擬退火算法是根據(jù)固體退火過程和組合優(yōu)化問題之間的相似性而提出的。在對物質(zhì)進(jìn)行加熱處理時(shí)，物質(zhì)組成中粒子之間的布朗運(yùn)動(dòng)加強(qiáng)，當(dāng)加熱到一定程度時(shí)，溫度達(dá)到物質(zhì)熔點(diǎn)，固體物質(zhì)會(huì)轉(zhuǎn)化為液體形態(tài)。這時(shí)，對物體進(jìn)行退火處理，使溫度降低，則物體的粒子運(yùn)動(dòng)減弱，并且會(huì)逐漸趨于平衡和有序，最終達(dá)到物質(zhì)性質(zhì)的穩(wěn)定。
模擬退火算法運(yùn)用溫度參數(shù)進(jìn)行控制，當(dāng)溫度較高時(shí)，數(shù)據(jù)運(yùn)動(dòng)變化劇烈，從而使解的區(qū)間變化較大，容易接受到較差解；當(dāng)溫度降低，數(shù)據(jù)運(yùn)動(dòng)逐漸減緩時(shí)，解的區(qū)間也會(huì)逐漸趨于穩(wěn)定，這時(shí)候就可以得到較為優(yōu)良的解果，從而對遺傳算法的不足進(jìn)行彌補(bǔ)。
2.3 退火遺傳算法依據(jù)
退火遺傳算法，是指以遺傳算法為主要運(yùn)算方法，并在運(yùn)算過程中引入模擬退火算法，使兩者達(dá)到優(yōu)勢互補(bǔ)，進(jìn)一步對群體進(jìn)行優(yōu)化調(diào)整。退火遺傳算法可以分為兩個(gè)組成部分：首先，運(yùn)用遺傳算法的進(jìn)化理論，產(chǎn)生一個(gè)相對較為優(yōu)良的群體，然后利用模擬退火算法，對群體中的個(gè)體進(jìn)行優(yōu)化和調(diào)整。
（1）針對遺傳算子進(jìn)行改進(jìn)
所謂遺傳算子，是指在遺傳算法中，用來維持遺傳多樣性所使用的算子，遺傳多樣性是生物或數(shù)據(jù)演化過程中不可或缺的一個(gè)必要性質(zhì)，遺傳算子在遺傳算法中類似于自然中的適者生存原則，對于個(gè)體的進(jìn)化會(huì)產(chǎn)生巨大的影響。
初始進(jìn)化階段，為了保持種群的多樣性，便于從中進(jìn)行選擇，應(yīng)該加大對于個(gè)體間相互交叉和互換的概率；在進(jìn)化的終極階段，頻繁的交叉互換不利于種群的穩(wěn)定和最優(yōu)解的產(chǎn)生，因此需要適當(dāng)?shù)販p小個(gè)體間的聯(lián)系和活動(dòng)，減少最優(yōu)解的求解難度，縮短求解過程。針對種群中的個(gè)體而言，在進(jìn)行變異操作時(shí)，對優(yōu)勢個(gè)體進(jìn)行較小的變異，劣勢個(gè)體進(jìn)行較大的變異，可以使其更加趨近于最優(yōu)解。
（2）合理構(gòu)造適應(yīng)值函數(shù)
適應(yīng)值函數(shù)可以針對遺傳算法的求解過程進(jìn)行指導(dǎo)，對最優(yōu)解的數(shù)值區(qū)間進(jìn)行限定，在適應(yīng)值函數(shù)的構(gòu)造過程中，引入關(guān)鍵分支的概念。關(guān)鍵分支，指在選定的路徑中，對存在的結(jié)點(diǎn)的真實(shí)性進(jìn)行判定，求解過程可能會(huì)在這些結(jié)點(diǎn)處產(chǎn)生偏離，引發(fā)錯(cuò)誤，而這些會(huì)導(dǎo)致求解過程偏離目標(biāo)路徑的結(jié)點(diǎn)，就是關(guān)鍵分支。
適應(yīng)值函數(shù)在遺傳算法中是用來區(qū)分個(gè)體優(yōu)劣的標(biāo)準(zhǔn)，是進(jìn)行自然選擇的唯一依據(jù)。原始適應(yīng)值函數(shù)是對問題最初求解目標(biāo)的反映。適應(yīng)值對個(gè)體的判斷有兩個(gè)截然相反的情形：適應(yīng)值越大，個(gè)體性能越好和適應(yīng)值越小，個(gè)體性能越好。在遺傳算法中，對適應(yīng)值函數(shù)是有限制的，即適應(yīng)值函數(shù)必須為非負(fù)數(shù)，這就需要選擇較大的適應(yīng)值函數(shù)來選擇較為優(yōu)良的個(gè)體。
為了使被測數(shù)據(jù)中每個(gè)參數(shù)都可以得到評估，根據(jù)相關(guān)數(shù)據(jù)對判斷結(jié)點(diǎn)進(jìn)行數(shù)據(jù)轉(zhuǎn)換，在保證個(gè)體數(shù)據(jù)得到充分計(jì)算的情況下，不會(huì)對程序主體造成破壞
3 實(shí)驗(yàn)結(jié)果與分析
為了對退火遺傳算法的性能進(jìn)行驗(yàn)證，采用判斷三角形的相關(guān)測試程序，將退火遺傳算法與單純的遺傳算法進(jìn)行對比，對進(jìn)化每一代的最大適應(yīng)值進(jìn)行記錄。
從實(shí)驗(yàn)數(shù)據(jù)可以看出，初始進(jìn)化階段，個(gè)體的產(chǎn)生具有隨機(jī)性，在對實(shí)驗(yàn)進(jìn)行多次運(yùn)行后，可以看出，最高適應(yīng)值之間差異十分明顯。進(jìn)化過程初期，兩種算法的最高適應(yīng)值都存在較大的波動(dòng)，而隨著遺傳的不斷進(jìn)行，退火遺傳算法的最大適應(yīng)值范圍逐漸趨于穩(wěn)定，而遺傳算法的最大適應(yīng)值范圍仍不穩(wěn)定。因此可以得出結(jié)論，將模擬退火算法與遺傳算法相互配合，可以有效避免單一遺傳算法的不足，加快對最優(yōu)解的計(jì)算速度，減少計(jì)算所需時(shí)間。根據(jù)實(shí)驗(yàn)的數(shù)據(jù)，對多次實(shí)驗(yàn)的結(jié)果進(jìn)行統(tǒng)一總結(jié)，可以看出，相對于單一的遺傳算法而言，退火遺傳算法的進(jìn)化速度大大加快，減少了計(jì)算時(shí)間。
4 結(jié)束語
經(jīng)過實(shí)驗(yàn)和分析，我們可以看到，生成高代碼覆蓋率的測試用例是自動(dòng)化測試的關(guān)鍵問題，是提高自動(dòng)化測試性能的主要手段。針對遺傳算法存在的缺陷，將遺傳算法和模擬退火算法相互結(jié)合，實(shí)現(xiàn)優(yōu)勢互補(bǔ)，針對群體數(shù)據(jù)中的遺傳算子以及適應(yīng)值函數(shù)作出改進(jìn)，最終通過對比實(shí)驗(yàn)，驗(yàn)證了退火遺傳算法的有效性和優(yōu)越性。
參考文獻(xiàn)：
[1]趙慧娟，孫文輝.基于退火遺傳算法的單元測試方法[J].計(jì)算機(jī)工程，2013，39（1）：49-53.
[2]楊學(xué)紅.自動(dòng)化單元測試概述[J].信息通信技術(shù)，2012，（1）：66-68.
摘 要:隨著汽車電子市場的快速發(fā)展，汽車控制器的電子控制單元(ECU)已越來越多，對ECU的功能測試也變得日趨復(fù)雜。為解決車載ECU功能測試，研究了基于控制器局域網(wǎng)絡(luò)(CAN)的ECU自動(dòng)測試方法。以NI公司的軟硬件為開發(fā)平臺(tái)、CAN總線為通信平臺(tái)搭建測試系統(tǒng)與被測ECU形成閉環(huán)結(jié)構(gòu)。通過CAN總線傳輸測試信息，可實(shí)現(xiàn)對同型號(hào)ECU的批量測試。此系統(tǒng)采用了新的測試方法來降低測試誤差，并支持ECU的流水線測試，大大降低了測試的復(fù)雜度，減少了工作量。同時(shí)，在完善仿真信號(hào)產(chǎn)生模塊和測試模塊用例庫后，也能適用于其他類型ECU的功能測試。
關(guān)鍵詞:
控制器局域網(wǎng)絡(luò)；電子控制單元；批量測試；汽車電子；車載網(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)場總線。其良好的實(shí)時(shí)性、可靠性和經(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各種信號(hào)后連接到ECU各輸入引腳，觸發(fā)它的各驅(qū)動(dòng)模塊進(jìn)行控制工作，有專門的線路負(fù)責(zé)數(shù)據(jù)交換，但這樣的測試系統(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)，采用人工對控制效果進(jìn)行直接的觀察和記錄。這些測試方法都加大了測試過程中的測試誤差、復(fù)雜度和測試工作量，且無法進(jìn)行自動(dòng)測試和結(jié)果的自動(dòng)生成，也不能同時(shí)對多個(gè)ECU進(jìn)行測試，給ECU廠商進(jìn)行批量生產(chǎn)時(shí)帶來很大的不便。
由此，引發(fā)了對新的測試方法的思考和探索。基于CAN總線的ECU功能測試方法以CAN總線的傳輸作為關(guān)鍵技術(shù)，采用閉環(huán)測試方法對同型號(hào)的ECU進(jìn)行自動(dòng)和批量測試。
1 基于CAN總線的ECU功能測試介紹
車載控制系統(tǒng)主要任務(wù)就是要解決車身電器設(shè)備的功能性問題，所以，首先應(yīng)關(guān)注ECU是否能實(shí)現(xiàn)功能上的控制，即測試其是否滿足控制協(xié)議的要求。ECU在控制功能上包括了通信服務(wù)功能、傳送數(shù)據(jù)功能、診斷信息及標(biāo)定信息功能、設(shè)備監(jiān)控和網(wǎng)絡(luò)管理功能等，具體的要求規(guī)范則由各ECU生產(chǎn)廠商自行制定。
目前應(yīng)用層協(xié)議制定分為以測試為重心的模式和以設(shè)計(jì)為重心的模式。不論哪種模式，控制器開發(fā)過程中，都需要通過測試來驗(yàn)證功能的正確性，確定ECU工作正常并不干擾總線正常通信［6］。
由圖1的控制器開發(fā)“V”模式圖可見，控制器開發(fā)過程包括多個(gè)環(huán)節(jié)，其中的應(yīng)用層功能測試是其重要組成部分，它包括ECU功能測試、網(wǎng)絡(luò)管理功能測試、故障診斷測試等，是進(jìn)行實(shí)車測試前的重要環(huán)節(jié)。在引入CAN總線后，將大大降低ECU功能測試的復(fù)雜度和測試工作量，是CAN總線測試的重要組成部分［7］。
在基于CAN總線的ECU測試系統(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總線作為測試的關(guān)鍵技術(shù)，充分發(fā)揮CAN總線在傳輸上的高可靠性和實(shí)時(shí)性等優(yōu)點(diǎn)。通過總線對仿真信號(hào)的測試報(bào)文進(jìn)行有效傳輸，如表1所示。
表1中：Message表示報(bào)文名稱；ID表示報(bào)文仲裁場；DLC表示報(bào)文長度；Data表示報(bào)文數(shù)據(jù)。
將報(bào)文與同型號(hào)ECU進(jìn)行連接，形成閉環(huán)測試結(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)行多次對比和測試后，在人機(jī)界面上對測試結(jié)果和各種信號(hào)量進(jìn)行直觀顯示，并利用測試結(jié)果自動(dòng)生成測試報(bào)告，優(yōu)化和改進(jìn)了傳統(tǒng)的測試方法。
2 設(shè)計(jì)方案
此方法采用仿真信號(hào)序列代替采集卡采集的真實(shí)信號(hào)，利用CAN總線的特點(diǎn)對數(shù)據(jù)進(jìn)行傳輸，并將整個(gè)測試構(gòu)建成閉環(huán)結(jié)構(gòu)，大大降低測試的復(fù)雜性。
2.1 方法總體框架
由CAN2.0協(xié)議可知，CAN報(bào)文的基本要素是報(bào)文ID、周期和信號(hào)與消息的映射關(guān)系。因此對ECU的協(xié)議功能測試，主要任務(wù)就是測試ID、消息周期、確定信號(hào)與消息的映射關(guān)系是否滿足要求，并測試在循環(huán)執(zhí)行多次之后，ECU是否具備在控制功能上的穩(wěn)定性［8］。
選用以LabVIEW為軟件平臺(tái)實(shí)現(xiàn)ECU的功能測試。測試系統(tǒng)整體框架包括三部分：上位機(jī)仿真和測試、CAN網(wǎng)絡(luò)和底層待測ECU模塊。如圖2所示。
工業(yè)計(jì)算機(jī)仿真給定ECU的各種信號(hào)量，驅(qū)動(dòng)ECU進(jìn)行控制工作。由于各ECU之間是相互獨(dú)立的，“測試與結(jié)果顯示模塊”采集不同ECU廣播的控制信息，并通過ID對它們進(jìn)行識(shí)別。對采集到的控制信息進(jìn)行分析、對比原始輸入來判定各個(gè)ECU在功能控制中是否滿足協(xié)議要求。
具體測試方法如下：
首先，通過上位機(jī)LabVIEW模擬仿真信號(hào)（如：轉(zhuǎn)向燈信號(hào)、溫度信號(hào)等）,通過NI 6259板卡，與待測ECU各引腳進(jìn)行對接；
然后，發(fā)送仿真信號(hào)，驅(qū)動(dòng)ECU進(jìn)行控制工作，并發(fā)送出相應(yīng)的CAN控制信息；
再次，通過NI 8473s板卡與上位機(jī)LabVIEW進(jìn)行對接，接收采集到的CAN報(bào)文，并通過LabVIEW實(shí)現(xiàn)報(bào)文的解析、處理和ECU控制效果的同步顯示；
最后，把原始仿真數(shù)據(jù)和處理后的數(shù)據(jù)進(jìn)行對比，驗(yàn)證ECU在功能控制上是否滿足預(yù)期效果，并對以上測試步驟循環(huán)多次，得出測試結(jié)論，生成測試文檔。
在此，根據(jù)測試大綱要求，選用一個(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)。具體的控制量與變化范圍因測試ECU功能要求進(jìn)行定制化處理。測試ECU仿真控制信號(hào)如表2所示。
2.2 軟件設(shè)計(jì)流程
上位機(jī)軟件整體分為7部分：虛擬儀器配置、模擬信號(hào)仿真、同步信號(hào)顯示、測試結(jié)果顯示、系統(tǒng)數(shù)據(jù)判斷、數(shù)據(jù)處理、測試報(bào)告生成。模塊示意圖如圖3所示。
1）虛擬儀器配置。對測試時(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)行控件顯示，方便測試者進(jìn)行直接觀察和分析。
4）測試結(jié)果顯示。在人機(jī)界面上進(jìn)行測試結(jié)果的顯示，以表格和BOOL數(shù)組的形式顯示出每個(gè)信號(hào)在多次測試之后的通過情況。
5）系統(tǒng)數(shù)據(jù)判斷。將處理后的CAN報(bào)文數(shù)據(jù)與預(yù)先保存的仿真信號(hào)數(shù)據(jù)進(jìn)行對比，得出測試結(jié)果。
6）數(shù)據(jù)處理。處理NI 8473s板卡采集到的CAN報(bào)文，提取數(shù)據(jù)信息。
7）測試報(bào)告生成。在人機(jī)界面上顯示測試結(jié)果后，將測試結(jié)果以網(wǎng)頁（.html）格式的文檔進(jìn)行保存，便于后期的分析和處理。
軟件設(shè)計(jì)流程如圖4所示。
3 系統(tǒng)分析
由圖2測試方法總體框架圖可知，此系統(tǒng)主要包含三部分：上位機(jī)仿真和測試、CAN網(wǎng)絡(luò)和底層待測ECU模塊。其中上位機(jī)仿真和測試模塊又分為仿真信號(hào)產(chǎn)生模塊和測試與結(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)，在板卡對應(yīng)引腳輸出對應(yīng)電壓信號(hào)。
由表2的ECU控制信號(hào)表可知，此待測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)行輸出，傳遞對應(yīng)電壓值到待測ECU,驅(qū)動(dòng)其進(jìn)行控制工作。
2）產(chǎn)生開關(guān)量仿真信號(hào)。
在LabVIEW中定義各種開關(guān)量信號(hào)，通過板卡產(chǎn)生高/低電平。一般情況下，ECU檢測到高邊信號(hào)（ECU有效電平分兩種：H、L，即高電平有效或低電平有效）后進(jìn)行控制工作（一般情況下，ECU的高電平判斷電壓在2.5V~5V），控制信號(hào)的開啟或關(guān)閉，并同步使用CAN模塊廣播CAN報(bào)文。
如：DriverDoorStatus（左前門狀態(tài)）,根據(jù)ECU手冊可知，其為BOOL量，所以在前面板中放置一個(gè)BOOL型控件。在對信號(hào)進(jìn)行操作處理后調(diào)用NI6259板卡的接口函數(shù)并配置通道信息，與此板卡進(jìn)行通信，產(chǎn)生所需仿真信號(hào)（此功能是否正常可通過示波器進(jìn)行驗(yàn)證）。
3.2 待測ECU模塊
車載ECU控制功能工作原理：ECU外接12V工作電壓，在人為進(jìn)行操作或發(fā)生狀態(tài)變化（如開啟轉(zhuǎn)向燈、水溫變化）時(shí)電路接通，然后產(chǎn)生電壓值傳遞到ECU的模擬輸入引腳，如圖7所示。
此系統(tǒng)使用板卡產(chǎn)生的各種電壓信號(hào)代替左側(cè)虛線部分圖中未見虛線，請補(bǔ)充或說明。，ECU檢測到信號(hào)后進(jìn)行控制工作。
3.3 測試與結(jié)果顯示模塊
上位機(jī)LabVIEW調(diào)用NI 8473s板卡接口函數(shù)采集CAN報(bào)文［12］。根據(jù)ECU控制協(xié)議，對CAN報(bào)文進(jìn)行解析、分析、處理，提取出周期、ID、DATA等控制信息。然后對比原始數(shù)據(jù)（3.1節(jié)部分），進(jìn)行多次測試后，如果每次測試都全部通過，則判斷為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 測試實(shí)現(xiàn)
測試ECU在控制功能上是否滿足給定的協(xié)議和規(guī)范，并測試在循環(huán)測試多次之后，ECU控制功能是否具有較好的穩(wěn)定性。測試系統(tǒng)人機(jī)界面如圖8所示。
“仿真信號(hào)控制部分”產(chǎn)生表1的ECU控制信號(hào)。“ECU控制顯示部分”是對接收到的CAN報(bào)文進(jìn)行解析、處理之后用控件進(jìn)行形象的顯示，并與“仿真信號(hào)控制部分”進(jìn)行對比。結(jié)果顯示，在循環(huán)測試100次之后，信號(hào)量“左前門狀態(tài)”和“進(jìn)氣歧管壓力信號(hào)”控制出錯(cuò)，在BOOL數(shù)組和測試表格中都有明確顯示。“ECU控制顯示部分”顯示出“左前門狀態(tài)”燈不亮以及進(jìn)氣歧管壓力信號(hào)數(shù)據(jù)不一致，這些也同樣說明了信號(hào)控制的錯(cuò)誤。在生成的測試報(bào)告(.html格式)中也有明確顯示，如圖9所示。
從測試過程中得知，各個(gè)ECU的觸發(fā)電平有可能不一樣，大致在5V~12V。NI 6259板卡的工作電壓需小于10V，所以在需要觸發(fā)電平高于10V的ECU上進(jìn)行測試時(shí)，則需要在板卡的輸出端加入一個(gè)增壓電路。
同時(shí)，為了保證測試的正確性，在使用示波器確認(rèn)仿真部分的輸出電壓無誤后，采用車載網(wǎng)絡(luò)測試專用工具CANoe對ECU控制報(bào)文進(jìn)行監(jiān)測，觀察結(jié)果如圖10如示。
由圖8和圖10可知，使用CANoe監(jiān)測的總線報(bào)文與測試系統(tǒng)監(jiān)測到的報(bào)文一致，驗(yàn)證了本文所設(shè)計(jì)測試方法的可行性和準(zhǔn)確性。在對比分析圖8和圖10中的監(jiān)測數(shù)據(jù)，驗(yàn)證了數(shù)據(jù)一致性和通信協(xié)議的可行性。
根據(jù)不同ECU的控制協(xié)議，制定不同的仿真信號(hào)產(chǎn)生模塊和測試模塊，并在使用過程中，不斷完善ECU的測試用例庫，在完善后進(jìn)行不同ECU功能測試時(shí)，進(jìn)行規(guī)格選擇后，即可實(shí)現(xiàn)對不同ECU的功能測試。
5 結(jié)語
本文介紹了ECU功能測試的現(xiàn)狀，優(yōu)化和改進(jìn)了傳統(tǒng)測試方法。此方法以仿真信號(hào)代替采集的真實(shí)信號(hào)來驅(qū)動(dòng)ECU進(jìn)行控制工作，并引入閉環(huán)結(jié)構(gòu)和CAN總線，使測試過程更加簡單和智能化。所測結(jié)果準(zhǔn)確可靠，能運(yùn)用于ECU生產(chǎn)線，提高ECU批量測試的工作效率，為整車廠進(jìn)行ECU測試帶來了方便。在完善仿真信號(hào)模塊和測試模塊用例庫后可擴(kuò)展到對不同型號(hào)ECU的功能測試。同時(shí)，此方法的思想，還可以應(yīng)用于車載網(wǎng)絡(luò)的測試、故障診斷等方面，具有較好的理論價(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的汽車測試方案［J］.汽車制造與裝備,2005(3):44-46.
[6]
程躍,康勁松,徐國卿.一種車用CAN總線網(wǎng)絡(luò)測試系統(tǒng)的研究［J］.電子應(yīng)用,2008,27(1):83-86.
[7]
梁銳.NI軟硬件平臺(tái)在汽車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ā)動(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)目:
國家“核高基”重大專項(xiàng)（2009ZX01038-002-002-2）；重慶高校優(yōu)秀成果轉(zhuǎn)化項(xiàng)目(KJZH08210)。
【關(guān)鍵詞】車頂單元；制冷量；設(shè)計(jì)
上世紀(jì)90年代后，隨著鐵路空調(diào)客車的飛速的發(fā)展，車頂單元式空調(diào)器的產(chǎn)量逐年增加。據(jù)不完全統(tǒng)計(jì)，目前國內(nèi)擁有空調(diào)器約20000多臺(tái)。值得注意的是投入運(yùn)用的空調(diào)器早已到了大修期，其中絕大部分為車頂單元式空調(diào)器。為保證檢修后的空調(diào)器的性能，客車車頂單元式空調(diào)器的檢修試驗(yàn)就顯得十分重要。
一、客車車頂單元式空調(diào)器的性能試驗(yàn)裝置
1、空調(diào)器的型號(hào)
目前，我國鐵路客車用空調(diào)器的主要型式是車頂單元式。該型空調(diào)器自1980年從日本引進(jìn)，仿制改進(jìn)，至今已經(jīng)運(yùn)用20多年，通過不斷地改進(jìn)完善，現(xiàn)在已經(jīng)形成標(biāo)準(zhǔn)化，系列化。空調(diào)器的結(jié)構(gòu)型式主要有三種：平底側(cè)出風(fēng)口型，代號(hào)為“—”；圓底下出風(fēng)型，代號(hào)為“Y”；平底側(cè)出風(fēng)口型，代號(hào)為“P”。平底側(cè)出風(fēng)型空調(diào)器安裝于客車車頂端部，新造客車安裝的絕大部分都是這種型式。
2、空調(diào)器的構(gòu)造
車頂單元式空調(diào)器是將機(jī)械制冷部分的壓縮機(jī)、冷凝器、干燥過濾器、毛細(xì)管(或膨脹閥)、蒸發(fā)器、氣液分離器、冷凝風(fēng)機(jī)、蒸發(fā)風(fēng)機(jī)和空氣預(yù)熱器等集中裝在一個(gè)箱體內(nèi)，組成一個(gè)單元，可方便地安裝在車頂部。與空調(diào)器配套的電氣控制柜安裝在車內(nèi)配電室，空調(diào)器與電氣控制柜通過電氣連接器(插頭、插座)連接，由發(fā)電車集中供電(亦可由本車懸掛式發(fā)電機(jī)供電)。空調(diào)器出風(fēng)口與車內(nèi)主風(fēng)道之間通過軟風(fēng)道連接，空調(diào)器處理后的空氣經(jīng)車內(nèi)主風(fēng)道由送風(fēng)口送入客室內(nèi)，達(dá)到調(diào)節(jié)車內(nèi)空氣溫度的目的。由此可見，客車車頂單元式空調(diào)器性能試驗(yàn)裝置的重要性。
3、設(shè)計(jì)原則
1）試驗(yàn)裝置結(jié)構(gòu)力求緊湊，占地面積盡量小，以求適應(yīng)于各類生產(chǎn)車間的工藝布局；
2）外形應(yīng)該美觀，設(shè)備整體性強(qiáng)；
3）工藝布置應(yīng)該靈活，工藝設(shè)計(jì)應(yīng)該簡單；
4）操作方便，參數(shù)的測試及數(shù)據(jù)處理要求準(zhǔn)確
4、設(shè)計(jì)方案的確定
目前現(xiàn)場使用的車頂單元式空調(diào)器性能裝置有閉路式和開路式兩種原理方法：
1）閉路式測試原理方法
該方式需要一間室外側(cè)試驗(yàn)室一間室內(nèi)試驗(yàn)室，被試空調(diào)器安裝于室外側(cè)試驗(yàn)室內(nèi)，該室內(nèi)的空氣溫度需要調(diào)節(jié)到名義工況下空調(diào)器冷凝器進(jìn)風(fēng)溫度，經(jīng)空調(diào)器制冷后的空氣由送風(fēng)道引入置于室內(nèi)側(cè)試驗(yàn)室的空氣流量測試裝置進(jìn)行空氣流量測量，接著進(jìn)入空氣調(diào)節(jié)裝置，調(diào)節(jié)后的空氣再由回風(fēng)道被空調(diào)器吸入，即完成了一次循環(huán)。空氣 參數(shù)調(diào)節(jié)及空氣流量測量均在風(fēng)道內(nèi)進(jìn)行，該方式的特點(diǎn)是測試環(huán)路必須密閉，熱濕損耗較小。
2）開路式測試原理方法
該方式與閉路式的區(qū)別在于，空氣經(jīng)過流量測量裝置后直接排入室內(nèi)側(cè)試驗(yàn)室內(nèi)，在房間內(nèi)進(jìn)行空氣調(diào)節(jié)。其優(yōu)點(diǎn)是室內(nèi)側(cè)試驗(yàn)室的空氣參數(shù)易于穩(wěn)定，但熱濕損耗較大。
對于這兩種方式，均需要設(shè)置獨(dú)立的試驗(yàn)房屋，房屋面積隨實(shí)際情況而定。被試空調(diào)器的安裝可采用固定式安裝架或試驗(yàn)小車。如果采用固定式安裝架，則一般采用箱式結(jié)構(gòu)，室外需設(shè)置空調(diào)器吊裝設(shè)備。若采用試驗(yàn)小車則一般采用房間式結(jié)構(gòu)（即由幾間相互隔熱的房間構(gòu)成）可在有起重機(jī)的檢修間將空調(diào)器吊裝到小車上，試驗(yàn)小車推入室外側(cè)試驗(yàn)室，接上管道即可進(jìn)行試驗(yàn)。
相比于房間式結(jié)構(gòu)，箱式結(jié)構(gòu)相對構(gòu)造簡單，占地面積較小，它的工藝布置也相對靈活，工藝設(shè)置簡單，不需要大量的土建工程。所以，本設(shè)計(jì)“以箱體式空調(diào)器試驗(yàn)裝置”作為總體設(shè)計(jì)方案。針對箱體式試驗(yàn)裝置的特點(diǎn)，其室內(nèi)可以安裝加熱加濕裝置，彌補(bǔ)室內(nèi)的熱濕損耗，所以我們選用開路式測試原理。綜上所述，我們本次設(shè)計(jì)方案最后確定為：“箱體結(jié)構(gòu)式的開路式測試”車頂單元式空調(diào)器性能裝置
二、制冷量的測量方法設(shè)計(jì)
1、設(shè)計(jì)原則
1）測量精度高，范圍寬，系統(tǒng)環(huán)節(jié)少；
2）測量裝置結(jié)構(gòu)力求緊湊，體積小，以適應(yīng)在箱體內(nèi)布局；
3）裝置安裝操作維護(hù)應(yīng)該方便，參數(shù)的讀取和數(shù)據(jù)的處理應(yīng)該力求簡單方便。
2、測量方案確定
目前，由于某些設(shè)計(jì)單位設(shè)計(jì)的試驗(yàn)裝置僅僅采用一種方法測試制冷量，不能有效地控制室外側(cè)空調(diào)器的冷凝器的進(jìn)風(fēng)溫度，造成試驗(yàn)工況的不穩(wěn)定，影響了測試精度。
《客車空調(diào)三機(jī)檢修及運(yùn)用管理規(guī)程》中規(guī)定，空調(diào)器制冷量達(dá)不到原參數(shù)的90％時(shí)，應(yīng)該分解制冷系統(tǒng)。這就要求所建的試驗(yàn)裝置工況要穩(wěn)定，測試數(shù)據(jù)應(yīng)該準(zhǔn)確。TB/T2432-93《鐵道客車車頂單元式空調(diào)器試驗(yàn)方法》中規(guī)定，空調(diào)器制冷量試驗(yàn)方法采用室內(nèi)側(cè)空氣焓差法為主測試方法，室外側(cè)空氣焓差法為輔測試方法。對于檢修性能試驗(yàn)裝置也可以只采用室外側(cè)空氣焓差法。但是為了保證試驗(yàn)裝置測試制冷量的的精度及使所測試空調(diào)器性能的穩(wěn)定性，我們采用室內(nèi)側(cè)空氣焓差法為主測試方法，室外側(cè)空氣焓差法為輔測試方法測試制冷。兩種方法測試的結(jié)果相對偏差不大于6％，若超出6％，則要進(jìn)行管路損耗修正。它的特點(diǎn)是穩(wěn)定性好，不受外界因素變化的影響。
3、測量原理方法
所謂室內(nèi)側(cè)空氣焓差法,即在規(guī)定工況下通過測得流經(jīng)空調(diào)器室內(nèi)側(cè)空氣焓差及量流量,經(jīng)過計(jì)算獲得有效制冷量的方法。
所謂室外側(cè)空氣溫差法,即在規(guī)定工況下通過測得流經(jīng)空調(diào)器室外側(cè)空氣溫差及重量流量，經(jīng)過計(jì)算獲得有效制冷量的方法。
三、制熱量的測量方法設(shè)計(jì)
1、設(shè)計(jì)原則
1）測量精度高，范圍寬，系統(tǒng)環(huán)節(jié)少；
2）測量裝置結(jié)構(gòu)力求緊湊，體積小，以適應(yīng)在箱體內(nèi)布局；
3）裝置安裝操作維護(hù)應(yīng)該方便，參數(shù)的讀取和數(shù)據(jù)的處理應(yīng)該力求簡單方便。
2、測量方案確定
我國車頂單元式空調(diào)器運(yùn)行在制熱狀態(tài)時(shí)候一般在冬季，采用的制熱方式一般是直接加熱。當(dāng)空調(diào)吸入的新鮮空氣和室內(nèi)的回風(fēng)在空調(diào)器加熱室內(nèi)被混合加熱后，將其直接送入客室內(nèi)即可，它相對于制冷狀態(tài)而言比較簡單，所以我們測試其制熱量時(shí)候可只用一種方法——室內(nèi)空氣焓差法測試即能滿足要求，為了保證熱損失在控制要求的范圍以內(nèi)，要用輸入電加熱器的瓦數(shù)所制得的熱量來驗(yàn)算（驗(yàn)算公式為qd=3.41·x，x為輸入電加熱器的瓦數(shù)，x可以在試驗(yàn)裝置控制柜上讀出來），若誤差大于6％則要進(jìn)行管路損失修正。若需要修正，修正方法為將兩種結(jié)果的差值加給室內(nèi)空氣焓差法計(jì)算的制熱量。
結(jié) 語
目前車頂單元式空調(diào)器在鐵道客車上的運(yùn)用已經(jīng)越來越多，但是空調(diào)器性能試驗(yàn)裝置的價(jià)格都非常高。因此，空調(diào)器的檢修和性能測試的是急需解決的問題，它直接關(guān)系鐵道客車運(yùn)營情況的好壞。車頂單元式空調(diào)器性能試驗(yàn)裝置能得到廣泛的應(yīng)用，有助于提高客車空調(diào)器的性能，從而提高鐵道客車乘坐的舒適度，也就在一定程度上提高了鐵道客車和其它交通工具的競爭力。
參考文獻(xiàn)
[1]王其偉.單元式空調(diào)器性能試驗(yàn)裝置的工況控制[J].鐵道車輛,2008(12)
關(guān)鍵詞關(guān)鍵詞：軟件工程；軟件質(zhì)量；單元測試；測試框架；面向?qū)ο虺绦?/p>
中圖分類號(hào)：TP302 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)文章編號(hào)：16727800（2013）008004503
0 引言
隨著現(xiàn)代軟件工程的不斷發(fā)展，人們對軟件質(zhì)量和生產(chǎn)力的要求越來越高。軟件測試技術(shù)和框架復(fù)用技術(shù)作為提高軟件質(zhì)量和生產(chǎn)力的有效手段，近年來倍受人們的重視。
傳統(tǒng)的“黑盒”、“白盒”測試技術(shù)主要應(yīng)用于面向過程的程序設(shè)計(jì)中。隨著面向?qū)ο蠹夹g(shù)的發(fā)展，這種技術(shù)已不能滿足軟件測試的需要。自動(dòng)化單元測試框架應(yīng)用于面向?qū)ο髥卧獪y試中，通過它來實(shí)現(xiàn)單元測試自動(dòng)化。
單元測試是對軟件進(jìn)行正確性檢驗(yàn)的測試工作，是軟件設(shè)計(jì)的最小單位。單元測試的目的主要是發(fā)現(xiàn)每個(gè)程序模塊內(nèi)部可能存在的錯(cuò)誤。程序員的基本職責(zé)是單元測試，單元測試能力是程序員基本能力的體現(xiàn)，程序員必須對自己所編寫的代碼認(rèn)真負(fù)責(zé)，軟件的質(zhì)量與程序員的工作效率直接受程序員單元測試能力高低的影響。
單元測試是一項(xiàng)很重要而且必要的工作。在實(shí)際工作中，許多程序員并不愿意對自己編寫的代碼進(jìn)行測試。軟件開發(fā)的工作壓力大，大多數(shù)程序員們因?yàn)闆]有時(shí)間測試自己的代碼，使程序的代碼質(zhì)量得不到保證，有些代碼還需重新編寫，程序員根本沒有時(shí)間對代碼進(jìn)行測試。自動(dòng)化單元測試框架能夠從根本上解決這個(gè)問題，它可以使測試工作變得簡單，這樣更有助于程序員進(jìn)行代碼開發(fā)工作。
1 自動(dòng)化單元測試框架設(shè)計(jì)目標(biāo)
自動(dòng)化單元測試框架的設(shè)計(jì)應(yīng)達(dá)到以下目標(biāo)：首先，框架簡單，可以使測試程序的編寫更簡化。框架使用常見的工具設(shè)計(jì)，測試工作操作簡單；其次，測試框架應(yīng)能夠使除作者以外的其他程序員進(jìn)行代碼測試，并能解釋其結(jié)果，即將不同程序員的測試結(jié)合起來，且不發(fā)生相互沖突。最后，測試用例可以復(fù)用，可以以現(xiàn)有的測試為起點(diǎn)形成新的測試。
本文將以這些目標(biāo)為指導(dǎo)，討論如何用以Kent Beck和Ralph Johnson提出的“模式產(chǎn)生體系結(jié)構(gòu)”的方式來設(shè)計(jì)框架系統(tǒng)。自動(dòng)化單元測試框架的設(shè)計(jì)思想是從0開始根據(jù)設(shè)計(jì)問題應(yīng)用設(shè)計(jì)模式，一個(gè)接一個(gè)逐步設(shè)計(jì)，直至獲得最終合適的系統(tǒng)架構(gòu)。其中實(shí)現(xiàn)部分采用Java語言來實(shí)現(xiàn)，并會(huì)使用UML圖來表示各種類及類間關(guān)系。
2 面向?qū)ο笞詣?dòng)化單元測試分析
自動(dòng)化測試定義為：管理與實(shí)施各種測試活動(dòng)，包括開發(fā)測試腳本、執(zhí)行測試腳本，這樣使驗(yàn)證測試需求更加方便，通過這些腳本實(shí)現(xiàn)了自動(dòng)測試，可以把它稱為自動(dòng)測量工具。使用這種自動(dòng)測試工具對增量軟件集成測試提供了巨大的方便，增加了巨大的價(jià)值。每一個(gè)新的構(gòu)件可以重用先前開發(fā)的測試腳本，即使需求和軟件有變更，作為一個(gè)重要的控制機(jī)制，自動(dòng)測試也能夠確保每一次重新構(gòu)建的穩(wěn)定性與準(zhǔn)確性。
3 面向?qū)ο笞詣?dòng)化單元測試框架
自動(dòng)化測試框架實(shí)質(zhì)是一種自動(dòng)測試工具，單元測試的核心問題是實(shí)現(xiàn)測試自動(dòng)化。一個(gè)完整的自動(dòng)化測試過程通常包括5個(gè)測試活動(dòng)，分別是測試標(biāo)識(shí)、測試設(shè)計(jì)、測試實(shí)現(xiàn)、測試執(zhí)行與評估。測試用例針對被測試系統(tǒng)的各項(xiàng)功能準(zhǔn)確地開發(fā)與設(shè)計(jì)，而且每一個(gè)測試用例都要按順序執(zhí)行這5個(gè)測試開發(fā)活動(dòng)，測試開發(fā)活動(dòng)如圖1所示。
圖1 測試活動(dòng)
測試標(biāo)識(shí)與測試設(shè)計(jì)這兩個(gè)測試活動(dòng)主要為智力活動(dòng)，分別標(biāo)識(shí)測試條件和設(shè)計(jì)測試用例。測試執(zhí)行與測試比較這兩個(gè)活動(dòng)屬于比較機(jī)械的活動(dòng)，它們的功能分別為：執(zhí)行測試用例、將測試輸出結(jié)果并與期望輸出結(jié)果值相比較。前兩個(gè)活動(dòng)決定了測試用例的質(zhì)量，后兩個(gè)活動(dòng)適合自動(dòng)化。在單元測試中，測試執(zhí)行和測試比較這兩個(gè)活動(dòng)要重復(fù)多次，測試標(biāo)識(shí)與測試設(shè)計(jì)通常只執(zhí)行一次。因此，在單元測試過程中，重復(fù)性的活動(dòng)特別需要自動(dòng)化執(zhí)行。
4 自動(dòng)化單元測試設(shè)計(jì)與實(shí)現(xiàn)
首先構(gòu)建對象來表達(dá)基本概念：Test Case（測試用例），然后將對象發(fā)送到測試框架，再由測試框架執(zhí)行，最后報(bào)告測試結(jié)果。
采用Command命令模式將一個(gè)請求封裝成一個(gè)對象，Command模式可以為每一個(gè)操作生成一個(gè)與之對應(yīng)的對象，同時(shí)能夠給出一個(gè)對應(yīng)的執(zhí)行方法。這樣可以對多個(gè)用戶請求進(jìn)行排隊(duì)，也可以將多個(gè)請求記錄到日志，并使用不同的請求對客戶進(jìn)行參數(shù)化。具體實(shí)現(xiàn)方法如下：
其中的run（）方法為模式中的執(zhí)行方法，可以通過繼承來重用該類，為了便于在測試失敗時(shí)能夠識(shí)別出失敗的測試，每一個(gè)Test Case在創(chuàng)建時(shí)都要給出與之對應(yīng)的名稱，這樣即可判斷出失敗的測試。
圖1展示了測試框架組成部分的快照，也展示了應(yīng)用于TestCase中的標(biāo)記。
圖1 測試框架組成部分
5 單元測試用例執(zhí)行流程
在實(shí)際測試過程中，構(gòu)造參數(shù)或資源、測試、釋放資源為測試的業(yè)務(wù)邏輯過程。例如，在測試數(shù)據(jù)庫的插入、更新、刪除、查詢等操作時(shí)，首先要對數(shù)據(jù)庫進(jìn)行連接，然后測試，最后釋放連接。這樣，在一個(gè)Test Case中有多個(gè)測試，需要反復(fù)書寫代碼，這增加了測試人員的工作量，不符合設(shè)計(jì)目標(biāo)。
建立測試支架即為所有的測試建立一個(gè)共同的結(jié)構(gòu)，可以解決以上問題，初始化代碼、測試代碼和釋放資源的代碼均放在測試支架上，每次運(yùn)行測試代碼之前，首先都運(yùn)行初始化代碼，最后運(yùn)行釋放資源代碼。這樣，每一個(gè)測試都會(huì)和與之對應(yīng)的支架一起運(yùn)行，而且測試結(jié)果互不影響，每一個(gè)結(jié)果都不會(huì)影響其它的測試結(jié)果。這樣便實(shí)現(xiàn)了代碼的復(fù)用，大大提高了軟件單元測試的工作效率。
以上通過模板方法實(shí)現(xiàn)，模板方法的Template Method靜態(tài)結(jié)構(gòu)如圖3所示。
其中，setUp方法初始化測試信息，如數(shù)據(jù)庫的連接，cleanUp方法的功能是測試結(jié)束后釋放資源。runTest方法的功能是進(jìn)行測試業(yè)務(wù)邏輯。TestCase的方法的功能為進(jìn)行測試邏輯框架的設(shè)計(jì)，run為模板方法。在這里，setUp和cleanUp可以被用來重寫，由框架來進(jìn)行調(diào)用。
6 測試結(jié)果收集
創(chuàng)建對象TestResult來收集運(yùn)行的測試結(jié)果，實(shí)現(xiàn)代碼如下：
UTF使軟件開發(fā)者們更愿意接受測試代碼的工作。有種種好處：UIT使測試用例的實(shí)現(xiàn)簡單、一致且模塊化；測試實(shí)現(xiàn)與執(zhí)行的特性支持迭代、增量開發(fā)；重新運(yùn)行測試包的便利使高頻率的回歸測試成為可能；同時(shí)它還能保證單元測試的持久性。此外，單元測試框架UTF也是可擴(kuò)展的，例如，利用Decorator模式，可以不斷向UTF添加新的功能；TestResult類也是框架的一個(gè)擴(kuò)展點(diǎn)。客戶能夠自定義它們的TestResult類，例如， HTMLTestResult可將結(jié)果上報(bào)為一個(gè)HTML文檔等。
參考文獻(xiàn)參考文獻(xiàn)：
[1] （美）普雷斯曼.軟件工程：實(shí)踐者的研究方法[M].北京：機(jī)械工業(yè)出版社，2011.
[2] （美）麥格雷戈.面向?qū)ο蟮能浖y試[M].北京：機(jī)械工業(yè)出版社，2002.
關(guān)鍵詞：軟件測試；單元測試；模擬對象
中圖分類號(hào)：TP311文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2008)05-00ppp-0c
1 引言
隨著極限編程在實(shí)際軟件開發(fā)項(xiàng)目中的推廣，越來越多的項(xiàng)目開始采用測試驅(qū)動(dòng)開發(fā)作為主要的軟件開發(fā)方法。單元測試不僅優(yōu)化了軟件系統(tǒng)設(shè)計(jì)，還大大簡化了功能測試的工作量[1]。但是另一方面．更多的項(xiàng)目在開始不久就發(fā)現(xiàn)在很多情況下針對一個(gè)類編寫單元測試比較困難．隨著項(xiàng)目的進(jìn)行，越來越多的代碼無法進(jìn)行單元測試．到最后整個(gè)項(xiàng)目無法繼續(xù)采用測試驅(qū)動(dòng)的方式進(jìn)行開發(fā)。因此，要將測試驅(qū)動(dòng)開發(fā)真正在整個(gè)項(xiàng)目里貫徹執(zhí)行，必須有一種方法能夠相對容易的解決這些問題。本文將首先討論了單元測試和無法或很難進(jìn)行單元測試的情況，然后引入Mock Object的概念，基于Mock Object實(shí)現(xiàn)單元測試。接下來討論在軟件開發(fā)過程中引入Mock Object對測試和設(shè)計(jì)的影響。最后簡述了Mock Object的局限性。
2 單元測試
2.1 什么是單元測試
單元測試是對程序中的單個(gè)子程序或過程進(jìn)行測試的過程，也就是說，一開始并不是對整個(gè)程序進(jìn)行測試，而是將注意力集中在對構(gòu)成程序的較小模塊的測試上面[2]。單元測試從兩個(gè)角度進(jìn)行測試：一是測試數(shù)據(jù)都是針對程序的功能來設(shè)計(jì)的黑盒測試；二是針對程序的邏輯結(jié)構(gòu)來設(shè)計(jì)測試用例的白盒測試。
2.2 單元測試面對的難題
造成針對一個(gè)類難以進(jìn)行單元測試的主要原因是因?yàn)檫@個(gè)類依賴于一些其它的難以測試的資源。主要有這三類最主要的資源：數(shù)據(jù)庫，第三方組件和網(wǎng)絡(luò)硬件資源。下面我們將對這三大類難以測試的資源進(jìn)行分類討論。
2.2.1 數(shù)據(jù)庫
現(xiàn)在大部分的軟件項(xiàng)目都會(huì)采用數(shù)據(jù)庫作為數(shù)據(jù)存儲(chǔ)。常見的開發(fā)團(tuán)隊(duì)會(huì)在每個(gè)開發(fā)人員的機(jī)器上安裝一個(gè)本地的數(shù)據(jù)庫，每個(gè)人針對自己的數(shù)據(jù)庫進(jìn)行開發(fā)調(diào)試。這樣做的問題是：必須有一種方式同步數(shù)據(jù)庫的設(shè)計(jì)。如果有一個(gè)人修改了數(shù)據(jù)庫schema或者某個(gè)存儲(chǔ)過程，這個(gè)修改必須同步到所有開發(fā)者的本地?cái)?shù)據(jù)庫以及測試服務(wù)器上。采用敏捷軟件開發(fā)的很多項(xiàng)目組往往會(huì)浪費(fèi)大量的時(shí)間在數(shù)據(jù)庫設(shè)計(jì)同步上。更嚴(yán)重的是每周都會(huì)遇到由于數(shù)據(jù)庫設(shè)計(jì)不同步，修改沖突導(dǎo)致的問題導(dǎo)致整個(gè)項(xiàng)目的中心源碼庫在Auto Build時(shí)失敗。每個(gè)開發(fā)人員都有自己的測試數(shù)據(jù)，除了上面提到的需要把這些測試數(shù)據(jù)同步到所有開發(fā)機(jī)器和測試服務(wù)器上外，還面臨更重大的問題。因?yàn)闇y試用例需要修改數(shù)據(jù)庫，因此還必須準(zhǔn)備一種機(jī)制能夠在每一個(gè)測試用例執(zhí)行結(jié)束后重新將所有的測試數(shù)據(jù)調(diào)入數(shù)據(jù)庫。采用最簡單直接的方法就是在每個(gè)測試用例執(zhí)行前都將數(shù)據(jù)庫清空，然后再將測試數(shù)據(jù)調(diào)入，這樣會(huì)大大減慢單元測試的時(shí)間。單元測試時(shí)間越長，開發(fā)者就越不愿意執(zhí)行這些測試用例，單元測試所發(fā)揮的作用越小，這也是很多測試驅(qū)動(dòng)項(xiàng)目最終無法進(jìn)行到底的一個(gè)重要原因。另一個(gè)非常嚴(yán)重的問題是為了清理測試環(huán)境，在針對商業(yè)邏輯的測試用例中加入了大量的數(shù)據(jù)訪問層的代碼。采用這樣的方式強(qiáng)迫開發(fā)者在開發(fā)商業(yè)邏輯層的同時(shí)開發(fā)數(shù)據(jù)訪問層，并且嚴(yán)重降低了可讀性。
2.2.2 第三方組件或應(yīng)用服務(wù)器
數(shù)據(jù)庫是最常見的第三方服務(wù)器。除此以外在越來越多的項(xiàng)目中使用第三方的組件和應(yīng)用服務(wù)器。例如：客戶環(huán)境中的ERP系統(tǒng),全球定位系統(tǒng)(GPS)的Web Service接口，繪圖引擎等。對于這些第三方提供的內(nèi)容，造成難以編寫單元測試的最根本的原因有：一是系統(tǒng)不透明：對于大部分商業(yè)組件或者服務(wù)來說，一個(gè)很重要的內(nèi)容是良好的封裝。但這個(gè)特性帶來的問題是在外界無法對其內(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)致無法為所有開發(fā)人員配置一個(gè)完全一致的環(huán)境。例如一個(gè)繪圖引擎的開發(fā)版的license是按照一個(gè)局域網(wǎng)內(nèi)部同時(shí)使用的人員個(gè)數(shù)收費(fèi)的，就不可能只為了能夠進(jìn)行完整的單元測試就為只編寫商業(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)致很難針對與他們相關(guān)的類編寫測試用例。
一是資源訪問沖突。很多網(wǎng)絡(luò)資源對于并發(fā)訪問的響應(yīng)協(xié)調(diào)是通過鎖機(jī)制進(jìn)行的，在實(shí)際項(xiàng)目中常見的是一個(gè)開發(fā)人員在調(diào)試本地代碼時(shí)導(dǎo)致遠(yuǎn)端資源被鎖定導(dǎo)致其它開發(fā)者無法訪問這些資源。
二是環(huán)境可控因素。對于網(wǎng)絡(luò)資源和硬件資源相關(guān)代碼的測試與針對商業(yè)邏輯層代碼的測試最大的不同是環(huán)境的不確定性。訪問網(wǎng)絡(luò)資源有可能遇到的異常情況非常多，例如網(wǎng)絡(luò)忙造成訪問超時(shí)，也有可能建立鏈接后數(shù)據(jù)傳輸失敗，還有可能數(shù)據(jù)傳輸完成后校驗(yàn)失敗。針對訪問這些資源的代碼進(jìn)行的測試必須能夠覆蓋到所有可能出現(xiàn)的每一種情況。如果沒有一個(gè)可控，并且是全自動(dòng)的環(huán)境輔助單元測試的話，這項(xiàng)任務(wù)基本上不可能完成。
3 模擬對象
3.1 什么是模擬對象
Mock這個(gè)單詞翻譯成中文大概的意思是假的，模擬的。如圖1所示：通過一個(gè)常見的對商業(yè)邏輯的測試描述了一個(gè)Mock Object。在圖中我們可以看出：測試代碼需要測試商業(yè)邏輯，而商業(yè)邏輯代碼需要通過IMyDataAccess接口訪問底層數(shù)據(jù)庫，這就是數(shù)據(jù)庫依賴問題。為了解決這個(gè)問題我們引入一個(gè)Mock Object，并將這個(gè)Mock Object而非真正的Data Access傳遞給商業(yè)邏輯代碼進(jìn)行測試。這里的Mock Object不需要實(shí)現(xiàn)任何邏輯只需要根據(jù)商業(yè)邏輯的需要返回適當(dāng)?shù)膬?nèi)容就可以了。
圖1 使用Mock Object對商業(yè)邏輯進(jìn)行測試
3.2 模擬對象實(shí)現(xiàn)單元測試應(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)在我們想測試transfer方法，它內(nèi)部調(diào)用的AccountManager的兩個(gè)方法。但是對于AccountManager來說，它只是個(gè)接口，如下：
public interface AccountManager {
Account findAccountForUser(String userId);
void updateAccount(Account account);
}
所以現(xiàn)在我們必須寫個(gè)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)基于一個(gè)接口定義Mock并實(shí)現(xiàn)這個(gè)接口的所有函數(shù)。
(2)創(chuàng)建Mock Object的一個(gè)對象
(3)設(shè)置對象內(nèi)部屬性
(4)告訴對象測試代碼希望看到的反應(yīng)
(5)進(jìn)行測試
(6)檢查Mock Object的確按照希望的順序進(jìn)行工作。
3.3 模擬對象的優(yōu)點(diǎn)
3.3.1 模擬對象作為測試手段的優(yōu)點(diǎn)
Mock Object最直接的優(yōu)點(diǎn)在于提供單元測試的質(zhì)量和覆蓋率：
(1)只要在測試中對期待發(fā)生的問題指定好執(zhí)行的順序引入Mock Object對象后的單元測試就是在一個(gè)完全可控的環(huán)境里進(jìn)行的。也就是說我們再也不會(huì)無法定位一個(gè)“時(shí)隱時(shí)現(xiàn)”的bug。相反我們可以非常迅速的將問題定位在一個(gè)類的內(nèi)部，而不是一個(gè)函數(shù)調(diào)用序列。
(2)于測試人員來說，最常見的問題是測試人員提交的bug無法在開發(fā)人員那里復(fù)現(xiàn)。有了Mock Object這個(gè)工具測試人員可以利用Mock Object明確的指定輸入和輸出編寫一個(gè)測試用例讓開發(fā)人員修復(fù)。
(3)超過8O％ 的異常處理代碼沒有被充分測試過。主要原因是在沒有Mock Object之前很多情況是無法由人工進(jìn)行控制的，例如寫文件失敗網(wǎng)絡(luò)連接超時(shí)，數(shù)據(jù)庫數(shù)據(jù)傳輸失敗或者從網(wǎng)絡(luò)接收到的數(shù)據(jù)已經(jīng)損壞。通過控制Mock Object我們很容易就可以模擬上面的這些情況。
3.3.2 模擬對象作為設(shè)計(jì)手段的優(yōu)點(diǎn)
雖然Mock Object最直接的優(yōu)點(diǎn)在于給予測試代碼更多的可控性和可操作性，它最大的優(yōu)點(diǎn)在于對軟件設(shè)計(jì)的影響[3]。
(1)測試驅(qū)動(dòng)開發(fā)與Mock Object一起使用，可以寫出低耦合高內(nèi)聚，非常優(yōu)雅干凈的代碼。
(2)強(qiáng)迫設(shè)計(jì)者放棄對第三方庫的強(qiáng)依賴關(guān)系，取而代之的是比較弱的依賴關(guān)系。
(3)設(shè)計(jì)人員可以將更大的注意力放在商業(yè)邏輯的實(shí)現(xiàn)和測試．由于Mock Object的存在，我們不需要實(shí)現(xiàn)數(shù)據(jù)訪問層就可以對商業(yè)邏輯進(jìn)行測試。而商業(yè)邏輯才是任何系統(tǒng)中對于客戶最重要的內(nèi)容，它的正確與否決定了整個(gè)系統(tǒng)是否能完成任務(wù)，它的穩(wěn)定性決定了整個(gè)系統(tǒng)架構(gòu)的穩(wěn)定性。
(4)在項(xiàng)目初期，甚至是中期，將設(shè)計(jì)人員解放出來，不用對系統(tǒng)底層的基礎(chǔ)設(shè)施做出判斷。例如，在商業(yè)邏輯并不明確，需求還不穩(wěn)定的時(shí)候，我們是更多根據(jù)感覺來做出很多重要的判斷的，而這些判斷往往導(dǎo)致比較關(guān)鍵的決定。例如，在項(xiàng)目之初，誰能夠明確的回答到底需要什么樣的數(shù)據(jù)庫？Oracle？SQL Server?還是XML文件？到底需要什么樣的隊(duì)列服務(wù)器 MSMQ還是IBM―MQ？由于Mock Object的引入，我們可以將這些決策推遲到商業(yè)邏輯層更加明確之后進(jìn)行，從而可以獲得更加準(zhǔn)確有針對性的答案。
3.4 模擬對象的局限性
Mock Object在實(shí)際項(xiàng)目中的應(yīng)用存在一些限制，一些是由于Mock Object本身性質(zhì)決定的，有一些則是由于其它類庫設(shè)計(jì)存在的缺陷導(dǎo)致的。
(1)一個(gè)典型的不是Mock Object的問題，而是類庫設(shè)計(jì)的問題。是Mock Object無法模擬比較深的對象樹。有一些第三方的類庫，尤其是一些消息處理函數(shù)的參數(shù)，提供的不是接口而是一些對象。往往這些對象內(nèi)部有很多子對象，也就是我們常說的一棵大的對象樹。我們需要花費(fèi)太多的精力去構(gòu)造這些對象來進(jìn)行模擬，時(shí)間消耗巨大。
(2)一般性而言，單元測試的粒度越細(xì)，功能測試的粒度就可以越粗[4]。但是引入Mock Object的單元測試仍然無法取代功能測試。一個(gè)很好的例子就是誤差積累的測試，哪怕每個(gè)單元的誤差都在可接收范圍內(nèi)，我們?nèi)匀恍枰粋€(gè)功能測試確保整體誤差也是可以接受的。
4 結(jié)束語
模擬對象解決了傳統(tǒng)單元測試的兩個(gè)問題：一是如何將需要測試的代碼與相關(guān)環(huán)境隔離；二是如何創(chuàng)建一個(gè)快速、可控的環(huán)境輔助測試開發(fā)。隨著模擬對象技術(shù)的成熟，基于模擬對象的單元測試會(huì)越來越廣泛地被采用。
參考文獻(xiàn)：
[1]Kent Beck.測試驅(qū)動(dòng)開發(fā)[M].北京:中國電力出版社,2003.
[2]Myers.王峰，陳杰譯.軟件測試的藝術(shù)（第二版）[M]. 北京:機(jī)械工業(yè)出版社,2006.50-52.
[3]David Astels.崔凱,譯.測試驅(qū)動(dòng)開發(fā)實(shí)用指南[M].北京:中國電力出版社,2004.120-130.
[4]Paul C Jorgensen.韓柯,杜旭濤,譯.軟件測試（第二版）[M].北京:機(jī)械工業(yè)出版社,2003.
【關(guān)鍵詞】Testbed/Tbrun 軟件單元測試 嵌入式
單元測試是保障軟件質(zhì)量的重要技術(shù)手段，其過程十分復(fù)雜，如果不借助輔助工具，僅靠人工處理，則不僅效率低下，工作量巨大，而且可能出現(xiàn)無法解決的問題。因此，利用一套好的單元測試工具幫助測試人員提高工作效率、工作質(zhì)量是非常必要的。
1 單元測試的定義
單元測試（圖1和圖2）是一個(gè)在隔離狀態(tài)下測試單個(gè)獨(dú)立軟件單元的過程，而集成測試（圖3）允許好幾個(gè)單元的同時(shí)分析，是多單元測試。因此，在單元測試時(shí)，需要模擬被測單元與其他模塊之間的交互，開發(fā)驅(qū)動(dòng)模塊和樁模塊構(gòu)建一個(gè)可執(zhí)行的環(huán)境。
2 單元測試的要求
單元測試重點(diǎn)要考慮的測試類型有：
2.1 功能測試
根據(jù)需求的關(guān)鍵成都選取相應(yīng)單元開展單元測試（建議需求的關(guān)鍵程度為關(guān)鍵、重要的單元應(yīng)100%開展單元測試，需求的關(guān)鍵程度為一般的單元可以通過代碼審查驗(yàn)證其功能）。
2.2 覆蓋率測試
根據(jù)軟件等級確定覆蓋率測試（見表1）。
3 如何達(dá)到充分的覆蓋率測試
3.1 根據(jù)對被測程序的期望實(shí)現(xiàn)的功能來構(gòu)造最有可能的功能測試
這些功能從軟件需求說明書或用戶文檔獲得。在加載測試數(shù)據(jù)的情況下，應(yīng)該能夠通過測試工具監(jiān)控源代碼的執(zhí)行。當(dāng)實(shí)現(xiàn)功能測試的數(shù)據(jù)用完后，檢查覆蓋率來發(fā)現(xiàn)程序中的哪些部分仍然沒有被測到。應(yīng)該進(jìn)一步的構(gòu)造測試數(shù)據(jù)并進(jìn)行執(zhí)行、分析。一直持續(xù)到進(jìn)行功能測試的數(shù)據(jù)被執(zhí)行完或者達(dá)到所需的測試度量標(biāo)準(zhǔn)。如果測試數(shù)據(jù)執(zhí)行完那么進(jìn)行（3.2）；否則的話（達(dá)到測試度量標(biāo)準(zhǔn)的要求）那么任務(wù)就完成了。
3.2 檢查測試覆蓋度量指標(biāo)
如果語句覆蓋率沒有達(dá)到完全覆蓋，那么可能是由于某個(gè)特殊的用例運(yùn)行失敗，錯(cuò)誤退出等造成的。為了將代碼中的每一行都執(zhí)行到，將程序執(zhí)行多次通常是必須的。通常功能測試只能覆蓋程序中40%到60%的可執(zhí)行語句。當(dāng)語句覆蓋達(dá)到完全，每一條語句都被執(zhí)行時(shí)，便可進(jìn)行（3.3）。
3.3 檢查所有沒有被執(zhí)行的分支
通常這些分支中的一部分可以通過構(gòu)造專門的用例實(shí)現(xiàn)對它們的測試。找出程序中未執(zhí)行分支，將分支測試充分實(shí)施后再進(jìn)行（3.4）。
3.4 有些沒有執(zhí)行到的分支和路徑，是由于相關(guān)的測試用例只有在程序執(zhí)行出錯(cuò)或者計(jì)算出錯(cuò)的錯(cuò)誤狀態(tài)下才能實(shí)現(xiàn)
這些通常是和程序的冗余保護(hù)設(shè)計(jì)相關(guān)，這樣的路徑應(yīng)該完整的保留。一旦不可行測試路徑被去掉，那么源代碼將會(huì)更加有效、健壯并且占用更少的空間。
4 Testbed/Tbrun在單元測試中的應(yīng)用
使用/Tbrun可自動(dòng)產(chǎn)生軟件測試的驅(qū)動(dòng)、樁模塊，從而節(jié)省時(shí)間，測試人員可將重點(diǎn)放在設(shè)計(jì)測試用例上，提高軟件測試效率。使用Testbed/Tbrun的基本方法：
（1）在已集成了開發(fā)環(huán)境的Testbed中加載被測軟件單元。
（2）創(chuàng)建并設(shè)計(jì)測試用例。設(shè)置輸入變量值。Testbed/Tbrun創(chuàng)建的測試用例，初始默認(rèn)的輸入變量有時(shí)可能不滿足實(shí)際執(zhí)行路徑的要求，也有可能存在當(dāng)前執(zhí)行路徑不需要的輸入變量，可將多余的輸入變量刪除掉，輸入變量選擇完成之后，根據(jù)希望被測函數(shù)執(zhí)行的路徑，設(shè)置各輸入變量的值；設(shè)置樁函數(shù)。Testbed/Tbrun能夠通過對被測函數(shù)的分析自動(dòng)為被測函數(shù)生成樁函數(shù)，在樁函數(shù)管理界面，選擇需要進(jìn)行設(shè)置的樁函數(shù)，分析判斷是否需要設(shè)置樁函數(shù)的返回值，還是需要通過調(diào)用樁函數(shù)改變某些全局變量的值；執(zhí)行測試用例。設(shè)置完成輸入變量和樁函數(shù)之后，就可以開始執(zhí)行測試用例了。
（3）查看覆蓋率信息。每成功執(zhí)行一個(gè)測試用例后，Testbed/Trbun都會(huì)統(tǒng)計(jì)當(dāng)前測試用例執(zhí)行的路徑以及相應(yīng)的覆蓋率，其中“S”表示語句覆蓋率，“B”表示分支覆蓋率，“MCDC”表示MC/DC覆蓋率，即修正條件/判定覆蓋率。
（4）動(dòng)態(tài)覆蓋率報(bào)告的保存。動(dòng)態(tài)覆蓋率報(bào)告以.c文件為基本單元，包含當(dāng)前.c文件中所有函數(shù)的動(dòng)態(tài)執(zhí)行情況，建議每執(zhí)行完成一個(gè)函數(shù)的單元測試之后，為各被測函數(shù)單獨(dú)保存動(dòng)態(tài)覆蓋率報(bào)告，在該報(bào)告中找到被測函數(shù)的具體動(dòng)態(tài)執(zhí)行信息。
在實(shí)際應(yīng)用中，需要注意以下幾個(gè)方面：
（1）main函數(shù)的測試。Testbed/Tbrun不支持直接對名稱為main的函數(shù)進(jìn)行單元測試，可通過修改main函數(shù)的名稱后再進(jìn)行單元測試，如將main函數(shù)名稱修改為testmain等。
（2）指針變量的測試。Testbed/Tbrun不支持直接對指針進(jìn)行引用的操作，容易跑飛，需要將指針映射到相應(yīng)的變量，Testbed/Tbrun支持對指針進(jìn)行映射。
（3）指針指向絕對的內(nèi)存地址。在頭文件中，代碼可能包含下列風(fēng)格，用#define來引入絕對內(nèi)存地址。例如：#define CONGIG_PAGE_1_ADDR 0x418000，然后在函數(shù)中直接從絕對地址中寫入和讀出數(shù)據(jù)。當(dāng)在一個(gè)主機(jī)/主機(jī)的測試環(huán)境中運(yùn)行這個(gè)函數(shù)時(shí)，內(nèi)存訪問違反將發(fā)生，易出現(xiàn)程序跑飛的現(xiàn)象。
5 結(jié)論
相對于完全人工測試，使用Testbed/Tbrun工具測試提高了工作效率、工作質(zhì)量。因此，Testbed/Tbrun可以較好地支持嵌入式軟件單元測試的開展。
關(guān)鍵詞：Testbed/Tbrun；軟件單元測試；嵌入式軟件
中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-2374（2013）18-0027-02
嵌入式軟件作為嵌入式系統(tǒng)的重要組成部分，嵌入式軟件質(zhì)量問題可能會(huì)帶來設(shè)備的損壞和人員的傷亡，因而用戶對其質(zhì)量有較高的要求。軟件測試是對軟件質(zhì)量檢驗(yàn)的一個(gè)非常重要的手段。而軟件測試中動(dòng)態(tài)測試最基礎(chǔ)的測試就是單元測試。如何開展單元測試以及如何提高單元測試的效率是一個(gè)值得研究的問題。
1 軟件單元測試的要求及重點(diǎn)
軟件單元測試是對軟件基本組成單元進(jìn)行測試，測試軟件單元是否正確地實(shí)現(xiàn)規(guī)定的功能，是否滿足軟件性能和接口要求。并驗(yàn)證程序與詳細(xì)設(shè)計(jì)說明的一致性。因此在單元測試時(shí)，需要模擬被測單元與其他模塊之間的交互，開發(fā)驅(qū)動(dòng)模塊和樁模塊兩種輔助模塊，構(gòu)建一個(gè)可執(zhí)行的環(huán)境，驅(qū)動(dòng)模塊用于模擬被測單元的上層模塊，測試執(zhí)行時(shí)由驅(qū)動(dòng)模塊調(diào)用被測單元使其運(yùn)行；樁模塊用于模擬被測單元在執(zhí)行過程中所調(diào)用的模塊。
單元測試重點(diǎn)考慮的測試類型有：（1） 接口測試。接口測試主要檢查實(shí)參與形參的數(shù)目是否相等、實(shí)參與形參的屬性是否匹配、實(shí)參與形參的單位是否一致、傳到被調(diào)用模塊的實(shí)參的屬性是否與形參的屬性匹配、是否把常量當(dāng)作變量傳遞等內(nèi)容。（2）功能測試。功能測試主要是對照軟件單元的設(shè)計(jì)說明，驗(yàn)證軟件是否完成了所需的功能。（3）重要執(zhí)行路徑測試。應(yīng)設(shè)計(jì)測試用例以發(fā)現(xiàn)錯(cuò)誤的計(jì)算、不正確的比較和不正常的控制流向等錯(cuò)誤。在計(jì)算中比較常見的錯(cuò)誤是：誤解或錯(cuò)誤處理算術(shù)運(yùn)算的優(yōu)先次序、混用不同類的操作、計(jì)算精度不夠等。另外在控制軟件執(zhí)行流程的比較操作中比較常見的錯(cuò)誤有：不同數(shù)據(jù)類型的比較、不正確的邏輯操作符或不正確的優(yōu)先次序、因精度不夠使本應(yīng)相等的數(shù)不相等（如浮點(diǎn)數(shù)）等。（4）軟件單元的局部數(shù)據(jù)結(jié)構(gòu)測試。軟件單元的局部數(shù)據(jù)結(jié)構(gòu)是一個(gè)主要的錯(cuò)誤來源，應(yīng)設(shè)計(jì)測試用例來發(fā)現(xiàn)不正確的或不一致的數(shù)據(jù)說明、初始化有錯(cuò)或沒有賦初值、不正確的變量名、不一致的數(shù)據(jù)類型、上溢/下溢或引用錯(cuò)誤等類型的錯(cuò)誤。（5）錯(cuò)誤處理路徑測試。一般軟件錯(cuò)誤處理路徑測試應(yīng)考慮下面幾種可能的錯(cuò)誤：對錯(cuò)誤的描述不易理解、指出的錯(cuò)誤并不是所遇到的錯(cuò)誤、出錯(cuò)時(shí)還沒有進(jìn)行出錯(cuò)處理就先進(jìn)行系統(tǒng)干預(yù)、錯(cuò)誤邊界條件的處理不正確、描述錯(cuò)誤的信息不正確從而不足以確定出錯(cuò)的原因等。（6）邊界測試。邊界測試是檢測軟件在其輸入/輸出域、過程參數(shù)、狀態(tài)轉(zhuǎn)換、功能界限等具有一定范圍的邊界或端點(diǎn)條件下的運(yùn)行情況，考核軟件的功能或性能在其邊界條件下或邊界的鄰近區(qū)域內(nèi)是否依然滿足設(shè)計(jì)要求。按照上去要求進(jìn)行單元測試時(shí)，為達(dá)到要求的覆蓋條件，還需采取一定的技術(shù)手段對測試覆蓋率進(jìn)行記錄和分析，確保達(dá)到相應(yīng)的覆蓋率指標(biāo)。采用TBrun單元級測試工具，能自動(dòng)產(chǎn)生軟件測試驅(qū)動(dòng)、樁模塊，提供友好的輸入輸出人機(jī)交互和覆蓋率統(tǒng)計(jì)功能，能有效提高單元測試的測試效率。
2 Testbed在單元測試中的應(yīng)用
使用 Testbed/TBrun的基本方法是：設(shè)計(jì)測試用例；在Testbed/TBrun中加載被測單元文件，通過Testbed/TBrun對被測軟件進(jìn)行源程序自動(dòng)插裝；根據(jù)測試用例設(shè)定輸入和預(yù)期的輸出，執(zhí)行插裝好的源程序單元；分析輸入數(shù)據(jù)、預(yù)期輸出和實(shí)際輸出；得到被測軟件在當(dāng)前的測試用例執(zhí)行過程中代碼的覆蓋率。需要注意的是，每執(zhí)行一個(gè)測試用例就需要重新編譯并執(zhí)行。Testbed/TBrun的覆蓋率統(tǒng)計(jì)只具有累加的功能，因此不能查詢每一測試用例執(zhí)行后的覆蓋率信息。在執(zhí)行完所有的測試用例后會(huì)生成一個(gè)總的覆蓋率文件，Testbed/TBrun通過對覆蓋率文件的分析得出軟件單元相應(yīng)語句的覆蓋情況，根據(jù)這些覆蓋情況可以較快確定冗余的測試數(shù)據(jù)并增補(bǔ)遺漏的測試數(shù)據(jù)，從而指導(dǎo)新的測試用例設(shè)計(jì)。在實(shí)際應(yīng)用Testbed單元測試時(shí)，需注意以下三個(gè)方面：（1）數(shù)組和指針類型的變量的輸入。數(shù)組可以通過在Testbed/TBrun插裝后的源代碼中插入數(shù)組的初始化語句對數(shù)組賦值或者在 Testbed/TBrun 環(huán)境中對數(shù)
組的一部分賦值。因指針不能被直接賦一個(gè)地址，所以輸入指針可采用映射的方式來賦值，將指針變量映射成相應(yīng)的自定義變量，然后對自定義變量賦值。在測試執(zhí)行的過程中，這個(gè)自定義變量的值就是指針的輸入值。（2）被測單元代碼的必要修改。在實(shí)際的測試過程中，有的代碼單元不能直接使用Testbed/TBrun直接執(zhí)行測試。須在分析之前對代碼單元做少量修改。如Testbed/TBrun 插裝源代碼時(shí)會(huì)生成 main（）函數(shù)，因此被測單元中的 main（）函數(shù)要改為其他的名稱以避免造成名字沖突；Testbed/TBrun 執(zhí)行分析時(shí)會(huì)執(zhí)行被測單元，因此被測單元中的 while（1）之類的死循環(huán)結(jié)構(gòu)要去掉，否則分析將無法結(jié)束。（3）模塊測試后顯示最終整體覆蓋率，不能查詢每一測試用例執(zhí)行后的覆蓋率信息。
3 結(jié)語
Testbed有效地支持了測試人員的測試工作，相對于完全人工測試提高了測試效率。該工具仍存在不足，還需在實(shí)踐中不斷完善使用方法。
參考文獻(xiàn)
本文就如何運(yùn)用反饋——矯正手段提高教學(xué)目標(biāo)效果談幾點(diǎn)看法。
一、在課前通過診斷性測試，獲得學(xué)生在學(xué)習(xí)新內(nèi)容前的知識(shí)反饋，為上新課做好準(zhǔn)備。
診斷性測試一般安排在新學(xué)期或新開課前進(jìn)行，測試時(shí)間一般5～10分鐘，測試應(yīng)側(cè)重于考查學(xué)習(xí)新課所需要掌握的基本知識(shí)和基本技能。例如，在上動(dòng)物模擬人體手術(shù)實(shí)驗(yàn)課前，先測試學(xué)生關(guān)于無菌技術(shù)和無菌原則方面的知識(shí)并補(bǔ)償，由此提高他們的學(xué)習(xí)外科手術(shù)的前提能力，最終提高實(shí)驗(yàn)?zāi)繕?biāo)。
二、在課前或課后，通過形成性測試了解學(xué)生的達(dá)標(biāo)情況，及時(shí)查漏補(bǔ)缺。
1、編制形成性測試題，包括課堂測試題和單元測試題，要確保適合各自的特點(diǎn)。
（1）課堂測試題，要適合在課堂教學(xué)中進(jìn)行測試。課堂教學(xué)時(shí)間一般以二學(xué)時(shí)為單位，共80分鐘。其中用以進(jìn)行課堂測試及反饋矯正的時(shí)間通常只有5分鐘，故編制此類試題要突出重點(diǎn)，考慮課堂操作的可行性，試題量不能過多。例如，在“復(fù)蘇”一章編制的課堂測試題為：①快速診斷心臟驟停的方法；②心肺初期復(fù)蘇的abc步驟；③心臟按壓有效的標(biāo)志是什么；④心肺復(fù)蘇有效的指標(biāo)是什么等。這些題中包括了本章的重要知識(shí)點(diǎn)，學(xué)生掌握后，在遇到心臟驟停病人時(shí)就會(huì)懂得如何去診斷和處理，而且試題量適中，便于在課堂上進(jìn)行測試和矯正。
（2）單元測試題，即教師根據(jù)教學(xué)的情況，一般按章節(jié)劃分為一個(gè)教學(xué)單元，每學(xué)完一個(gè)單元后進(jìn)行一次單元測試，以評價(jià)學(xué)生的單元達(dá)標(biāo)情況。單元達(dá)標(biāo)測試覆蓋的目標(biāo)范圍較大，而且每一目標(biāo)都應(yīng)有相應(yīng)的檢測題，測試時(shí)間為20～30分鐘，測試內(nèi)容多時(shí)間少，因此編制此類題主張多用選擇題和判斷題，少用填空題、名詞解釋和問答題，以方便學(xué)生答題，做到既能檢測目標(biāo)又不影響課堂授課。此處，通過定期的單元測試，又能促使學(xué)生經(jīng)常系統(tǒng)地進(jìn)行復(fù)習(xí)，有利于知識(shí)的鞏固和強(qiáng)化。
2、編制平行性測試題，此類試題適用于對矯正生的檢測。
即用以檢測單元測試中的未達(dá)標(biāo)者，在經(jīng)過補(bǔ)救矯正后是否已達(dá)標(biāo)。編制此類別試題應(yīng)與單元形成性測試題是同質(zhì)不同形的，即用不同的試題形式去檢測同一目標(biāo)。例如，檢測“補(bǔ)鉀原則”這一目標(biāo)時(shí)，如果在單元形成測試中采用選擇形式，則在平行性測試中可采用判斷或填空題的形式進(jìn)行檢測。
三、反饋——矯正是對經(jīng)測試反饋的未達(dá)標(biāo)者及時(shí)補(bǔ)救矯正，使其達(dá)標(biāo)。
1、課堂反饋矯正。
課堂測試反饋一般采用提問、回答、接力填空等形式，其中最常用的是課堂提問的形式，而課堂提問的形式主要適合于對個(gè)別學(xué)生，這與目標(biāo)教學(xué)要面向全體學(xué)生的宗旨是矛盾的，為了解決這一矛盾，在提問時(shí)應(yīng)使所提問的學(xué)生具有代表性和隨機(jī)性。所謂代表性是指所提問的學(xué)生能代表全班學(xué)生中的某一部分，如優(yōu)生、中等生或差生。要做到有計(jì)劃有目的地進(jìn)行提問檢測，尤其對差生要多進(jìn)行檢測矯正。隨機(jī)性主要是針對課堂教學(xué)的具體情況，在全班同學(xué)中隨機(jī)地進(jìn)行提問。筆者曾在上“急性闌尾炎”一節(jié)時(shí)，發(fā)現(xiàn)一位同學(xué)在上課時(shí)開小差，當(dāng)時(shí)立即對她進(jìn)行提問檢測：“急性闌尾炎最有特征的癥狀是什么？”她回答是“腹痛”。這樣通過提問，可及時(shí)地使她調(diào)整思維、融入課堂。雖然她答得不全對，但是通過提問既能起到對她及時(shí)補(bǔ)救矯正的效果，同時(shí)也能引起其他同學(xué)的重視（尤其是對提問的這一問題的重視），結(jié)果在單元形成測試中全班同學(xué)都能答對這一題。這樣通過抓典型、抓代表，達(dá)到“牽一發(fā)而動(dòng)全身”的效果，既能及時(shí)糾正課堂上出現(xiàn)的個(gè)別問題，又能調(diào)動(dòng)全班同學(xué)的課堂積極性和主動(dòng)性，因而能有效地提高教學(xué)目標(biāo)達(dá)成度。
市建設(shè)經(jīng)濟(jì)運(yùn)行信息管理系統(tǒng)是建立在j2EE框架基礎(chǔ)上，其BLE(BizLogicHandler)是J2EE框架中的Domain層的實(shí)現(xiàn);BPO(Business Persistence Object)是DAO與BO的結(jié)合體，對應(yīng)J2EE中Persistence層的實(shí)現(xiàn);Web層開發(fā)采用Struts框架。涉及各政府職能部門，和下屬鄉(xiāng)鎮(zhèn)政府，轄區(qū)大中型企業(yè)、重點(diǎn)企業(yè)和新招商企業(yè)等諸多干系人，需要實(shí)現(xiàn)系統(tǒng)查詢、問題反映、信息上報(bào)，信息審查，網(wǎng)上辦公，跟蹤督辦，即時(shí)通訊，短信提醒，報(bào)表打印等主要功能。
對于應(yīng)用系統(tǒng)的測試，我們劃分為單元測試、部件組合測試、功能測試、性能測試和驗(yàn)收測試。其中重點(diǎn)關(guān)注了單元測試和性能測試，下面分別介紹。
單元測試階段，我們采用開發(fā)人員自己寫測試代碼、小組內(nèi)同級審查和測試組抽查相結(jié)合的測試策略。要求單元測試應(yīng)用緊接在編碼編譯通過之后，鼓勵(lì)進(jìn)行測試先行(即先編寫測試用例，然后用測試驅(qū)動(dòng)代碼的實(shí)現(xiàn))。
單元測試工具采用junit測試框架。因?yàn)椋覀兊拈_發(fā)語言是JAVA，開發(fā)工具采用的是MYECLIPSE，而junit是當(dāng)前JAVA自動(dòng)化單元測試的實(shí)際標(biāo)準(zhǔn)，MYECLIPSE對junit提供了很好的支持。
對Action部分使用StrutesTestCase進(jìn)行單元測試，StrutsTestCase for Junit是對標(biāo)準(zhǔn)Junit中TestCase的擴(kuò)展，可以對Strus framework的測試提供方便。我們使用了其中的Mock object方法，測試Action objects、mappings、form beans以及forwords declarations，它不需要servlet引擎及web application container的環(huán)境，而且StrutsTestCase提供了許多“validation methods”，方便測試案例編寫。我們采取的原則是，盡可能的把邏輯代碼從jsp/servlet/action中移出，使用Junit作單元測試。該系統(tǒng)單元測試中面臨兩個(gè)脫離，脫離BizDelegate(封裝了對Session Fa?ade 的調(diào)用過程，降低Application 層與Services層的耦合性)對action進(jìn)行測試，脫離BPO對BLH進(jìn)行單元測試，為此我們使用EaseMock技術(shù)，為一個(gè)接口創(chuàng)建一個(gè)模仿對象，將模仿對象作為參數(shù)來調(diào)用域代碼，具體為測試者提供了抽取方法和工廠方法。
為了保證測試的質(zhì)量，我們測試之初就設(shè)置了專門的測試小組。在單元測試階段，該小組監(jiān)控所有的測試活動(dòng)和任務(wù)的執(zhí)行情況，對測試的總體進(jìn)行跟蹤、控制和報(bào)告，對于類的提交，我們制定了嚴(yán)格的審核過程。首先，開發(fā)人員測試自己的類;然后小組內(nèi)審查人員審查相應(yīng)的類，打上已審查標(biāo)記;最后，測試小組審核和抽查已審查的測試類和代碼;測試小組還需要根據(jù)審核和抽查情況進(jìn)行統(tǒng)計(jì)分析，調(diào)節(jié)測試資源分布。
在性能測試階段，我們分為四個(gè)階段實(shí)施;啟動(dòng)階段、準(zhǔn)備階段和分析階段。測試工具采用Rational Test Manager 2003，測試環(huán)境包括local computer和Test agent，Local computer作為測試平臺(tái)的控制主機(jī)，負(fù)責(zé)整個(gè)測試的計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行和評估，作為Test agent的機(jī)器，統(tǒng)一接收由Local computer，最后由Local computer生成統(tǒng)計(jì)報(bào)告。在測試中我們也發(fā)現(xiàn)響應(yīng)時(shí)間慢的問題，在經(jīng)過對服務(wù)器的調(diào)優(yōu)，以及相應(yīng)部分的代碼優(yōu)化、SQL優(yōu)化之后，性能得到明顯改善。
下面簡單介紹性能測試中我們對遇到的問題所采取的策略：
(1)該系統(tǒng)采用的是J2EE架構(gòu)的一種模式，GUI客戶端直接和服務(wù)器連接，采用的是BEA公司獨(dú)有的T3協(xié)議，而且前自動(dòng)化測試工具能夠錄制和回放腳本的大都是基于HTTP協(xié)議的瀏覽器客戶端方式。對此，我們采取自動(dòng)錄制和手工編寫腳本相結(jié)合的方式，對于瀏覽器客戶端的測試，采用自動(dòng)測試工具錄制腳本;對于GUI客戶端的測試，用JAVA配以性能測試工具提供的API包，手動(dòng)或半手動(dòng)編寫測試腳本。
(2)該系統(tǒng)業(yè)務(wù)功能繁多，測試需要準(zhǔn)備的數(shù)據(jù)量大，而測試時(shí)間短。我們分析出業(yè)務(wù)具有代表性的重要和關(guān)鍵用例，并且利用開發(fā)過程已有的客戶端程序，減少測試腳本的開發(fā)量。
(3)該系統(tǒng)渠道多，與外部系統(tǒng)接口復(fù)雜，而且系統(tǒng)采用多家公司產(chǎn)品，如果出現(xiàn)問題，分析和定位困難。對此，我們利用性能測試檢驗(yàn)客戶和系統(tǒng)之間的交互，包括瀏覽器和GUI客戶端等方式的連接。同時(shí)在進(jìn)行性能測試的時(shí)候，將內(nèi)部各種系統(tǒng)，與其連接的各外部系統(tǒng)的日志和監(jiān)控工具全部打開，記錄各部分的處理過程，這樣當(dāng)發(fā)現(xiàn)性能問題時(shí)，便能及時(shí)的定位瓶頸出現(xiàn)的位置;測試環(huán)境準(zhǔn)備和測試時(shí)，請相關(guān)廠家的工程師提供現(xiàn)場支持，進(jìn)行性能監(jiān)控和問題分析。
由于采用了適當(dāng)?shù)臏y試方法、測試策略和測試工具，總體來看，我們的測試取得了不錯(cuò)的效果，有力地保證了項(xiàng)目的質(zhì)量，XX市經(jīng)濟(jì)運(yùn)行信息系統(tǒng)現(xiàn)已正式穩(wěn)定的運(yùn)行，也受到用戶的好評，這是我們重視軟件開發(fā)過程的測試保證軟件質(zhì)量的結(jié)果。當(dāng)然也有不足的地方，具體存在以下幾個(gè)方面;
(1)開發(fā)人員的測試觀念還不夠強(qiáng)，雖然我們制定了良好的單元測試策略，但開發(fā)人員并沒有很好的執(zhí)行，以至于在以后階段的測試和運(yùn)行中受害不淺。
(2)每種測試之前，我們都組織力量充分準(zhǔn)備了測試方案，但是在測試數(shù)據(jù)的準(zhǔn)備上，由于系統(tǒng)復(fù)雜性等多方面的原因，有些數(shù)據(jù)準(zhǔn)備的不夠完備。
要解決以上問題，我認(rèn)為首先還是要樹立開發(fā)人員的測試?yán)砟睿挥袕木唧w的開發(fā)人員做起，才能整整提高測試的質(zhì)量，其次還要堅(jiān)決貫徹執(zhí)行項(xiàng)目中確立的測試方法和策略。
我們從實(shí)踐中領(lǐng)會(huì)到，測試確實(shí)可以在保證軟件質(zhì)量方面起到很大的作用。但同時(shí)我們也認(rèn)識(shí)到，測試中還有很多領(lǐng)域和知識(shí)需要繼續(xù)研究和實(shí)踐，新技術(shù)的發(fā)展對測試也提出了新的要求和挑戰(zhàn)，我們將在測試領(lǐng)域不斷探索，不斷創(chuàng)新，為我國電子政務(wù)建設(shè)和企業(yè)信息化建設(shè)多做貢獻(xiàn)。
作者：孟曉微 來源：科學(xué)與財(cái)富 2010年11期
