專利名稱：一種軟件測試方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電子或通信領(lǐng)域的測試技術(shù)，尤指一種軟件測試方法。
背景技術(shù)：
在電子或通信領(lǐng)域，為實現(xiàn)各種功能或應(yīng)用，都需要建設(shè)各種相應(yīng)的系統(tǒng)或網(wǎng)絡(luò)，在所述的系統(tǒng)或網(wǎng)絡(luò)中，除了必需的硬件以外，還配備了各種相應(yīng)的軟件，為了保證所述系統(tǒng)及網(wǎng)絡(luò)的正常運用，除了保證硬件的正常工作外，還必須保證軟件的正常工作，為此就有必要在系統(tǒng)或網(wǎng)絡(luò)正式運用前，對其中的軟件進(jìn)行測試。
目前實現(xiàn)軟件測試的方法很多，但基于測試實現(xiàn)方法(單元測試，集成測試和系統(tǒng)測試)的考慮，測試技術(shù)分為系統(tǒng)內(nèi)測試(被測試系統(tǒng)和測試用例運行在同一應(yīng)用程序內(nèi))和系統(tǒng)外測試(被測試用例運行在被測試系統(tǒng)外)兩類，各自有其優(yōu)點和缺點，下面簡單進(jìn)行說明系統(tǒng)外測試在被測試系統(tǒng)外部獨立運行，系統(tǒng)內(nèi)部信息不能直接得到，只能通過系統(tǒng)外部接口(如界面，網(wǎng)絡(luò)接口等)進(jìn)行操作來達(dá)到測試目的。測試用例的改變不影響被測試系統(tǒng)，但對系統(tǒng)內(nèi)部運行一無所知，不能實現(xiàn)白盒測試。
系統(tǒng)內(nèi)測試方法需要和被測試系統(tǒng)進(jìn)行聯(lián)合編譯(如極限編程eXtremeProgramming所提出的CPPUNIT和JUNIT，DUNIT，CUNIT等方法)，或者在被測試系統(tǒng)內(nèi)部做統(tǒng)一樁模塊(類似計算機(jī)病毒)，由外部程序通過某種通信方式控制樁模塊進(jìn)行操作。
聯(lián)合編譯測試的特點是用例對系統(tǒng)內(nèi)部的存取很方便，但測試用例的修改將停止系統(tǒng)運行，將修改后的測試用例和被測試系統(tǒng)一起進(jìn)行編譯和鏈接，然后再運行，這樣將一次次的關(guān)閉系統(tǒng)，達(dá)不到對被測試系統(tǒng)的連續(xù)和長時間測試的目的，同時使測試過程過于繁雜，操作不便。
在被測試系統(tǒng)外邊界實現(xiàn)的黑盒測試如圖1所法，被測試系統(tǒng)對外有若干個接口，如果對被測試系統(tǒng)進(jìn)行測試，需要在不同接口處進(jìn)行模擬和觀察，通過模擬被測試系統(tǒng)對外的交互和觀察驗證實現(xiàn)測試目的。
這種黑盒測試的缺點如下1、測試實現(xiàn)難度大由于是針對被測試系統(tǒng)(System Under Test，SUT)外部接口進(jìn)行驗證，而被測試系統(tǒng)SUT的外部接口種類繁雜，因此測試接口的編寫是一項非常龐大的工作，例如該接口是E1接口，測試用例需要驗證從E1發(fā)來一條消息，則測試過程的實現(xiàn)只能是，在連接被測試系統(tǒng)E1接口的設(shè)備上通過某種手段發(fā)送來此消息，有時候需要做專門的E1測試接口，實現(xiàn)起來比較麻煩，很多時候需要獨立硬件的支持。
2、測試驗證充分度不夠由于是在外部實現(xiàn)對被測試系統(tǒng)的黑盒測試，被測試系統(tǒng)內(nèi)部的情況一無所知，因此針對內(nèi)部接口的測試無法實現(xiàn)，必須通過在被測試系統(tǒng)內(nèi)部增加有關(guān)的額外代碼將所需要的內(nèi)部信息輸出來，才可以驗證外部測試執(zhí)行對被測試系統(tǒng)的影響，這樣就增加了被測試系統(tǒng)的復(fù)雜度。
3、部分異常測試難以實現(xiàn)由于是在被測試系統(tǒng)外部進(jìn)行測試，部分異常情況難以模擬，如時序測試等，則這種測試模型下由于系統(tǒng)結(jié)構(gòu)限制基本很難成功實現(xiàn)。
現(xiàn)有技術(shù)中，還有一種白盒測試方法，如圖2、圖3所示，此種測試模型中，所有的測試用例在測試代碼樁中實現(xiàn)，測試代碼樁中實現(xiàn)了測試邏輯，并且受測試控制中心的控制來執(zhí)行測試，測試控制中心和測試代碼樁連接，并且向它下發(fā)測試用例執(zhí)行命令，可帶有簡單的參數(shù)，測試結(jié)果通過測試控制中心輸出出來，如果只需要無選擇的測試，也可不需要測試控制中心，程序啟動自動執(zhí)行測試，并將結(jié)果通過被測試系統(tǒng)提供的接口輸出出來。
在編譯過程中需要被測試系統(tǒng)的源代碼或者是庫文件，連同被測試代碼樁一起進(jìn)行編譯和鏈接，測試代碼樁需要和被測試系統(tǒng)的編譯和鏈接選項一致，如果不一致將導(dǎo)致錯誤出現(xiàn)。
白盒測試的缺點如下1、維護(hù)麻煩需要和被測試系統(tǒng)進(jìn)行聯(lián)合編譯和鏈接，如果需要補充測試用例，還需要將系統(tǒng)停掉，然后修改被測試代碼，并同被測試系統(tǒng)進(jìn)行聯(lián)編，運行聯(lián)編后得到的可執(zhí)行程序執(zhí)行測試。如果系統(tǒng)在單板上運行，則加載的時間可能會非常長，這樣將大大影響測試效率。
2、兩類程序相互影響有可能測試代碼和被測試系統(tǒng)(SUT)采用不同的相互影響的編譯選項，導(dǎo)致編譯或者鏈接不能通過，公共資源(如函數(shù)，變量等)有可能沖突等都屬于這種情況?；蛘邷y試代碼引進(jìn)了其他的第三方軟件模塊和SUT編譯鏈接存在沖突，導(dǎo)致測試不能進(jìn)行下去。
3、目標(biāo)代碼大由于所有的測試用例都被聯(lián)編，這樣將導(dǎo)致聯(lián)編后的目標(biāo)程序非常大，相當(dāng)不靈活，對系統(tǒng)的加載和啟動等也帶來很大的麻煩。如果將測試用例分開，則將分別聯(lián)編，這樣測試執(zhí)行將只能不斷啟停系統(tǒng)，也很麻煩，且做不到連續(xù)測試的目的，對于一些需要連續(xù)測試觀察的應(yīng)用場合不適用。

發(fā)明內(nèi)容
本發(fā)明提供一種軟件測試方法，結(jié)合上述黑盒測試模型和白盒測試模型的優(yōu)點，在實現(xiàn)白盒測試的基礎(chǔ)上實現(xiàn)測試用例與被測試系統(tǒng)相互獨立，測試用例的生成也不受被測試系統(tǒng)影響。
本發(fā)明提供的軟件測試方法，包括下列步驟A)編寫一動態(tài)加載模塊，包含測試用例和資源指針的定義，所述資源指針指向測試用例中需要用到的被測試系統(tǒng)的資源；B)在被測試系統(tǒng)中加入加載測試樁模塊，該加載測試樁模塊的作用是將編譯后的測試用例的動態(tài)加載模塊加載到被測試系統(tǒng)中；C)生成上述已加入加載測試樁模塊的被測試系統(tǒng)的MAP文件，用該MAP文件中的資源定位信息對所述資源指針賦值，實現(xiàn)資源映射；D)動態(tài)加載模塊從加載測試樁模塊接收測試命令，執(zhí)行測試。
根據(jù)本發(fā)明的上述方法，所述步驟B中的加載測試樁模塊可用源代碼或者鏈接庫的方式加入到被測試系統(tǒng)中。
根據(jù)本發(fā)明的上述方法，所述步驟C中實現(xiàn)資源映射的具體方法為將MAP文件中需要映射的資源地址解析出來放在一個獨立文件中，所述動態(tài)加載模塊讀取該獨立文件進(jìn)行解析，實現(xiàn)資源映射。
根據(jù)本發(fā)明的上述方法，所述步驟C中實現(xiàn)資源映射的具體方法為將MAP文件中需要映射的資源地址解析出來直接加入到動態(tài)加載模塊代碼中編譯，直接實現(xiàn)資源映射。
根據(jù)本發(fā)明的上述方法，其特征在于所述步驟B中在被測試系統(tǒng)中加入加載測試樁模塊后還包括有一加載控制中心與所述加載測試樁模塊實現(xiàn)通信，實現(xiàn)通信的過程為該加載控制中心發(fā)起加載/卸載命令和測試操作命令；所述加載測試樁模塊接收并解析加載控制中心發(fā)出的加載/卸載命令，將動態(tài)加載模塊加載到被測試系統(tǒng)或從被測試系統(tǒng)中卸載動態(tài)加載模塊；所述加載測試樁模塊將加載控制中心發(fā)來的執(zhí)行測試命令傳遞給動態(tài)加載模塊，控制所述動態(tài)加載模塊實現(xiàn)測試。
根據(jù)本發(fā)明的上述方法，所述加載測試樁模塊控制所述動態(tài)加載模塊運行于獨立任務(wù)或統(tǒng)一任務(wù)模式實現(xiàn)測試過程。
根據(jù)本發(fā)明的上述方法，所述加載控制中心實現(xiàn)還與其它用戶測試模塊的通信，其過程為接收其它用戶測試模塊發(fā)出的命令，將接收的命令發(fā)往所述加載測試樁模塊，并將測試結(jié)果信息顯示給用戶。
根據(jù)本發(fā)明的上述方法，所述加載控制中心還與用戶直接進(jìn)行信息交互，其過程為接收用戶發(fā)出的命令，將接收的命令發(fā)往所述加載測試樁模塊，并將測試結(jié)果信息顯示給用戶。
根據(jù)本發(fā)明的上述方法，所述測試用例采用與被測試系統(tǒng)不同的編譯型編程語言實現(xiàn)。
本發(fā)明技術(shù)方案帶來的有益效果如下1、方便實現(xiàn)軟件測試的黑白盒測試，使測試用例可以同時實現(xiàn)黑盒測試和白盒測試所具有的益處，包括黑盒測試的相對獨立性和白盒測試對于SUT內(nèi)部資源的可視化和可操作性。使測試過程和被測試系統(tǒng)(SUT)的關(guān)聯(lián)和耦合程度可以由測試人員靈活掌控。
2、測試用例管理和維護(hù)方便靈活，獨立于具體的被測試系統(tǒng)(SUT)，便于實現(xiàn)測試模塊的組件化和標(biāo)準(zhǔn)化。
3、測試設(shè)計和實現(xiàn)的復(fù)雜度降低，提供給測試人員在用例設(shè)計編碼語言上更多的選擇，以及在測試過程中的多任務(wù)實現(xiàn)。


圖1為現(xiàn)有技術(shù)中的黑盒測試示意圖。
圖2為現(xiàn)有技術(shù)中的白盒測試被測系統(tǒng)運行過程示意圖。
圖3為現(xiàn)有技術(shù)中的白盒測試被測系統(tǒng)編譯過程示意圖。
圖4為本發(fā)明方法測試過程示意圖。
具體實施例方式
參見圖4，為本發(fā)明方法測試過程示意圖。如圖所示，在被測試系統(tǒng)(SUT)中加入加載測試樁模塊(LTM)，該LTM模塊在SUT編譯前加入，作為一個獨立的模塊，可用源代碼或者鏈接庫的方式加入到被測試系統(tǒng)中，它的功能是如下1、管理多個動態(tài)加載模塊(DLM)的加載和卸載過程，每個DLM實現(xiàn)不同的測試目的，相互獨立，并實現(xiàn)這些加載模塊運行于獨立任務(wù)/統(tǒng)一任務(wù)模式的支持。所述獨立任務(wù)不占用SUT本身任務(wù)的執(zhí)行時間，即一般的獨立線程模式，統(tǒng)一任務(wù)需要占用SUT任務(wù)來執(zhí)行。
2、受加載控制中心(LCC)的操作控制，將動態(tài)加載模塊文件加載到被測試系統(tǒng)中，并實現(xiàn)動態(tài)加載模塊和加載控制中心之間的通信。LTM通過解析加載控制中心發(fā)來的加載/卸載命令實現(xiàn)將動態(tài)加載模塊文件加載到被測試系統(tǒng)中或從被測試系統(tǒng)中卸載動態(tài)加載模塊。
加載測試樁模塊(LTM)的具體實現(xiàn)如下1、通過某種進(jìn)程間通信機(jī)制(如網(wǎng)絡(luò)各種方法、RPC，DCOM等，或者操作系統(tǒng)支持的如IPC、命名管道等)和加載控制中心LCC進(jìn)行通信，通過某種機(jī)制(如網(wǎng)絡(luò)通過不同的端口，不同的命名管道名等)將LCC發(fā)來的連接通道作為統(tǒng)一任務(wù)/獨立進(jìn)程通道(根據(jù)測試需要和目的而定，如果針對的是被測試系統(tǒng)內(nèi)部的集成測試和單元測試，可采用統(tǒng)一任務(wù)，如果需要模擬被測試系統(tǒng)外部的其他實體即系統(tǒng)之間的交互測試，可采用獨立任務(wù))，如果是統(tǒng)一進(jìn)程，則收到LCC發(fā)來的命令后直接執(zhí)行，如果是獨立任務(wù)，則需要生成新任務(wù)，將該通道轉(zhuǎn)到新任務(wù)中執(zhí)行和LCC的通信。
2、接收LCC發(fā)來的命令，解析其中的LOAD和UNLOAD命令，實現(xiàn)動態(tài)加載模塊的裝載和卸載。
3、LTM如果判斷和LCC的通道中斷，則執(zhí)行加載模塊卸載，同時釋放該通道(可選的異常處理)。
動態(tài)加載模塊(DLM)，包括測試用例，實現(xiàn)的功能如下1、設(shè)置被測試系統(tǒng)中的資源(包括函數(shù)和變量)指針定義原型。
2、在初始化時讀入被測試系統(tǒng)(包括加載測試樁模塊)的MAP文件，根據(jù)MAP文件中的資源定位信息設(shè)置DLM中資源指針，使DLM中的資源指針指向?qū)嶋H的SUT內(nèi)資源，實現(xiàn)資源映射。
3、響應(yīng)加載控制中心發(fā)來的執(zhí)行測試命令，執(zhí)行DLM中定義的接口函數(shù)實現(xiàn)測試。
動態(tài)加載模塊(DLM)的具體實現(xiàn)如下1、首先編寫動態(tài)鏈接模塊，在其中制訂SUT中的資源指針定義，如下
void(*fln1)(VOS_INT32 iNum)＝0；struct StructList*list；其中fln1為SUT中存在的函數(shù)，list是SUT中的StructList全局變量list指針，當(dāng)然也可以包括其他類型資源，如類實例，數(shù)組等等。
2、定義指針變量映射數(shù)組，如果在DLM中包括的頭文件中已經(jīng)存在有函數(shù)的定義，則需要進(jìn)行函數(shù)實體的空定義如下FucMap 1Map[]＝{{(unsigned long*)&fIn1，″fin1″}，{(unsigned long*)&list，”list”}…}3、提供MAP文件將這些指針進(jìn)行靜態(tài)映射的手段讀取map文件中fln1的描述，將SUT MAP中的fln1的地址給fln1指針，這樣在動態(tài)加載模塊中對fln1的引用將實現(xiàn)直接調(diào)用SUT中的引用。
注意需要在DLM和SUT中定義函數(shù)原型要一致，如果采用不同的編程語言則要保證函數(shù)的參數(shù)出入棧順序是一致的，即在函數(shù)定義前加入函數(shù)類型標(biāo)識符，如_fastcall，_stdcall等等。
4、提供函數(shù)補丁功能，將被補丁的函數(shù)地址保存，加入跳轉(zhuǎn)到新函數(shù)的指令，同時提供被補丁函數(shù)恢復(fù)功能。
動態(tài)加載模塊可以實現(xiàn)預(yù)定義的接口函數(shù)，LTM在加載進(jìn)來后執(zhí)行這些預(yù)定義接口函數(shù)，將MAP文件中的資源映射關(guān)系(資源如函數(shù)和全局變量與SUT內(nèi)的地址對應(yīng)關(guān)系)映射進(jìn)動態(tài)加載模塊的指針中。具體的實現(xiàn)過程用MAP文件中定義的地址對指針賦值。
在DLM實現(xiàn)SUT MAP文件的映射可以采取多種實現(xiàn)方式，包括但不限于下述方法將MAP中需要映射的資源地址解析出來放在一個獨立文件中，在DLM中讀取文件解析，實現(xiàn)映射。
將MAP中需要映射的資源地址解析出直接放在DLM代碼中編譯。
加載控制中心(LCC)實現(xiàn)功能如下1、實現(xiàn)和SUT中LTM的通信功能，發(fā)起加載/卸載動態(tài)模塊的命令，以及發(fā)起測試操作命令。該模塊外部可以和用戶直接進(jìn)行交互，也可以和其他用戶測試模塊通信，接收命令發(fā)往LTM。
2、將動態(tài)加載模塊(DLM)中測試執(zhí)行結(jié)果信息顯示給用戶，或者發(fā)回給其他用戶測試模塊。
加載控制中心(LCC)的具體實現(xiàn)如下1、加載控制中心根據(jù)配置信息或者用戶/其他測試工具的命令，通過和LTM之間的通信機(jī)制，發(fā)起建立和LTM的連接通道。
2、LCC根據(jù)用戶命令和LTM進(jìn)行交互，實現(xiàn)測試目的。并將DLM中測試用例執(zhí)行過程中返回的信息顯示出來。
LCC和LTM之間的通信可以采用任何系統(tǒng)間/系統(tǒng)內(nèi)進(jìn)程間通信的機(jī)制，包括但不限于網(wǎng)絡(luò)，RPC，IPC等方法。
LCC是可選的，用戶可以直接通過連接到LTM發(fā)命令實現(xiàn)相同功能。
LCC和LTM之間的通信如軟件協(xié)議可以采取任何協(xié)議形式，也可以采用現(xiàn)有的腳本技術(shù)實現(xiàn)(如PYTHON和TCL等)。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)該以權(quán)利要求書的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.一種軟件測試方法，包括下列步驟A)編寫一動態(tài)加載模塊，包含測試用例和資源指針的定義，所述資源指針指向測試用例中需要用到的被測試系統(tǒng)的資源；B)在被測試系統(tǒng)中加入加載測試樁模塊，該加載測試樁模塊的作用是將編譯后的測試用例的動態(tài)加載模塊加載到被測試系統(tǒng)中；C)生成上述已加入加載測試樁模塊的被測試系統(tǒng)的MAP文件，用該MAP文件中的資源定位信息對所述資源指針賦值，實現(xiàn)資源映射；D)動態(tài)加載模塊從加載測試樁模塊接收測試命令，執(zhí)行測試。
2.如權(quán)利要求1所述的方法，其特征在于所述步驟B中的加載測試樁模塊可用源代碼或者鏈接庫的方式加入到被測試系統(tǒng)中。
3.如權(quán)利要求2所述的方法，其特征在于所述步驟C中實現(xiàn)資源映射的具體方法為將MAP文件中需要映射的資源地址解析出來放在一個獨立文件中，所述動態(tài)加載模塊讀取該獨立文件進(jìn)行解析，實現(xiàn)資源映射。
4.如權(quán)利要求2所述的方法，其特征在于所述步驟C中實現(xiàn)資源映射的具體方法為將MAP文件中需要映射的資源地址解析出來直接加入到動態(tài)加載模塊代碼中編譯，直接實現(xiàn)資源映射。
5.如權(quán)利要求1、2、3或4所述的方法，其特征在于所述步驟B中在被測試系統(tǒng)中加入加載測試樁模塊后還包括有一加載控制中心與所述加載測試樁模塊實現(xiàn)通信，實現(xiàn)通信的過程為該加載控制中心發(fā)起加載/卸載命令和測試操作命令；所述加載測試樁模塊接收并解析加載控制中心發(fā)出的加載/卸載命令，將動態(tài)加載模塊加載到被測試系統(tǒng)或從被測試系統(tǒng)中卸載動態(tài)加載模塊；所述加載測試樁模塊將加載控制中心發(fā)來的執(zhí)行測試命令傳遞給動態(tài)加載模塊，控制所述動態(tài)加載模塊實現(xiàn)測試。
6.如權(quán)利要求5所述的方法，其特征在于所述加載測試樁模塊控制所述動態(tài)加載模塊運行于獨立任務(wù)或統(tǒng)一任務(wù)模式實現(xiàn)測試過程。
7.如權(quán)利要求5所述的方法，其特征在于所述加載控制中心實現(xiàn)還與其它用戶測試模塊的通信，其過程為接收其它用戶測試模塊發(fā)出的命令，將接收的命令發(fā)往所述加載測試樁模塊，并將測試結(jié)果信息顯示給用戶。
8.如權(quán)利要求5所述的方法，其特征在于所述加載控制中心還與用戶直接進(jìn)行信息交互，其過程為接收用戶發(fā)出的命令，將接收的命令發(fā)往所述加載測試樁模塊，并將測試結(jié)果信息顯示給用戶。
9.如權(quán)利要求1所述的方法，其特征在于所述測試用例采用與被測試系統(tǒng)不同的編譯型編程語言實現(xiàn)。
全文摘要
本發(fā)明有關(guān)一種軟件測試方法，包括A)編寫一動態(tài)加載模塊，包含測試用例和資源指針定義，所述資源指針為測試用例中需要用到的指向被測試系統(tǒng)的資源；B)在被測試系統(tǒng)中加入加載測試樁模塊，該加載測試樁模塊將編譯后的動態(tài)加載模塊加載到被測試系統(tǒng)中；C)生成上述已加入加載測試樁模塊的被測試系統(tǒng)的MAP文件，用該MAP文件中的資源定位信息對上述資源指針賦值，實現(xiàn)資源映射；D)動態(tài)加載模塊從加載測試樁模塊接收測試命令，執(zhí)行測試。采用本發(fā)明方法能實現(xiàn)軟件黑白盒測試，測試用例管理和維護(hù)方便靈活，測試實現(xiàn)復(fù)雜度低。
文檔編號G06F11/36GK1744055SQ20041007904
公開日2006年3月8日 申請日期2004年9月4日 優(yōu)先權(quán)日2004年9月4日
發(fā)明者盧慶明 申請人:華為技術(shù)有限公司