一種程序調測系統及方法
2023-06-06 04:22:46 2
專利名稱：一種程序調測系統及方法
技術領域：
本發明涉及軟體調試與測試領域，特別涉及能夠通過形式描述調試過程來實現白盒測試的程序測試系統及方法。
背景技術：
在IT產品研發中，軟體調試與測試佔用大量工作時間，提高這兩者的工作效率將直接加快產品研發進度，提高這兩者工作質量也將直接提升產品質量、降低研發風險。對軟體調試與測試操作實現形式化描述，是提高效率的必要條件。但是，目前主流的白盒測試工具普遍只對測試操作實施形式化描述，很少把調試操作描述成腳本並將其自動轉化為測試用例來重複執行。
目前本領域主要的白盒測試工具，例如針對C語言測試的CodeTest、針對C++的CppTest、針對Java的JUnit等工具，都在一定程度實現了測試操作的形式化描述。無論測試描述是一種腳本語言，還是採用與被測系統開發相同的程式語言(如JUnit就是用Java寫測試用例對Java程序做測試)，都實現了操作過程形式化描述。當測試操作以規範語言方式記錄時，重複測試就成為可能，而且，形式化記錄有利於對操作過程進行檢視、評估，以及改進。在白盒測試中，為了根據代碼被測試覆蓋的情況來完善測試用例，需要用腳本描述測試操作。
但這些主流白盒測試工具絕大部分沒有對調試操作進行形式化描述。某些程式語言工具雖然已局部地實現了調試操作的形式化描述，例如在Tornado Shell中以命令行交互方式寫腳本做調試，但這種腳本更多只是為了調試功能的增強，很難被重用於測試。
將軟體調試操作轉化為規範測試腳本，存在以下瓶頸問題1、調試操作是被測系統運行後在線進行的，而現有的眾多測試工具只支持靜態方式設計用例。
當調試操作自動轉化為測試腳本時，調、測成為一體了，調試的在線特徵也要求測試需要在線進行。否則，對從調試轉化來的腳本難以立即進行調整、評估及優化。目前多數白盒測試工具沒有支持在線方式(即不重啟被測系統)的設計用例。被測系統運行後，不能在線編寫和在線運行用例，也不能在線查看其運行結果並改進測試設計，最終導致調試記錄難以轉化為實用的測試用例。
2、調試操作隨意性大，很難轉化為有效的測試用例即使有一種技術能將所有調試操作都記錄為腳本，但對所有調試記錄都進行記錄又過於繁雜，而且很難維護用例。若只取局部操作，又容易喪失操作前後的相關性。同時，調試針對代碼行，因為源碼易變，同樣導致用例難於維護。
而且，調試操作很隨意，如果直白轉換同樣使測試腳本很隨意，給工作效果評估帶來困難。
第4代白盒測試方法綜合了軟體白盒測試的最佳實踐，反映了現今白盒測試的發展方向，屬於公共領域的通用方法論。根據第4代白盒測試方法的要求，測試工具應採用一種技術能將調試操作規範地記錄下來。
發明內容
針對現有技術存在的上述問題，並且為了適應第4代白盒測試方法的要求，本發明著眼於以下幾個方面，提供了一種新的程序測試系統和測試方法1、採用一種語言映射技術使測試驅動能在線進行，並使用一種腳本化的打樁技術。
這樣，測試樁也能夠進行在線模擬。通過使測試驅動與測試樁的腳本化和在線化，使得測試操作可以在線進行，從而將測試設計從靜態模式轉化為動態模式。
2、把細粒度的調試轉換為粗粒度的檢視。
由於調試操作基於代碼行，隨意性大，函數內代碼是經常修改的，必然導致調試操作重用性差。因此，通過基於函數調用接口的檢視操作，函數原型的穩定性相對要高些，可避免調試生成的腳本過於繁雜，或因原始碼易變導致的可維護性差的問題。
3、引入一種新的調試工作有效性的評估方法。
該方法能夠適應調試轉測試的應用場景，以及適應第4代白盒測試方法的要求。
根據本發明的一個方面，提供了一種程序測試系統，所述程序測試系統包括測試主機和目標機，所述測試主機對所述目標機的程序進行調測，其中，所述目標機中包含調用轉向模塊，所述調用轉向模塊包括轉向配置子模塊，用於配置被測試程序的被測函數完成一次轉向所需的配置項，所述配置項設置在轉向控制表中；轉向控制子模塊，識別主調函數與被調用函數，根據轉向控制表中的配置項控制主調函數的當前調用轉向到測試專用函數；和樁函數調用子模塊，根據轉向控制子模塊的當前調用轉向控制，調用相應的測試專用函數。
根據本發明的另一方面，提供一種程序測試方法，包括配置被測試程序的被測函數完成一次轉向所需的配置項；識別主調函數與被調用函數，控制主調函數的當前調用轉向到測試專用函數；和根據轉向控制子模塊的當前調用轉向控制，調用相應的測試專用函數進行測試。
其中，測試專用函數既包括測試中動態定義的腳本函數，也包括在被測系統中預先駐留的函數。
本發明的優點在於採用了一種腳本化的補丁技術，讓測試樁能用腳本來定義，實現測試樁在線定義、在線更新，支持將靜態測試設計轉化為動態、在線的模式，因而大幅度提高測試設計的工作效率。另外，在線測試還帶來「所見即所得」的應用模式，對終端用戶更為友好，人機互動方式更加人性化。
軟體調試過程實現形式化描述後，調試操作可記錄、可重複，在此基礎上為適應程序測試的需要，採用一定規格與形式將調試操作轉化為檢視描述，形成規範的測試用例。這使得程序測試真正重用調試操作，提高了測試腳本的開發與調試的效率，並且解決了現有技術因調試的隨意性與代碼行的易變性而帶來自動生成用例的可維護性差的問題。
採用上述腳本化補丁技術，還實現一種可定製的，等效於語句覆蓋與分支覆蓋的測試程度評估方法。本方法不僅支持測試工具的快速實現，降低開發成本，可定製的形式也有利於測試過程能按平穩質量向前推進。
概括而言，本發明可大幅度提高軟體白盒測試的效率，提高測試操作的易用性，另外還有利於測試質量得到保障，這些優點已在現有VcTester工具的推行實踐中得到體現。
圖1顯示了根據本發明的在被測系統中駐留的調用轉向模塊的結構示意圖；圖2顯示了根據本發明的實現函數調用轉向的原理圖；圖3顯示了根據本發明的實現跳轉控制前後的調用關係；圖4是根據本發明一個實施方式的腳本補丁操作流程圖；圖5顯示了根據本發明的自擴展調試器的行號入棧與出棧過程；圖6顯示了本發明用於實現在線測試系統的框架結構；圖7顯示了本發明中測試代理模塊的層次結構；圖8顯示了映射支持模塊的初始化過程；圖9顯示了映射實例的生成過程；圖10示例性地顯示了一個映射實例的TData與TType對應關係；圖11示例性地顯示了根據本發明的映射實例的屬性。
具體實施例方式
下面將結合附圖對本發明的程序測試系統及方法的實施方式進行詳細的說明。
圖1顯示了根據本發明的一個實施方式的在被測系統中駐留的調用轉向模塊10的結構示意圖。該模塊用於在被測函數調用時將其調用改向，使測試專用函數能替代原有函數來運行。調用轉向模塊10包括三個子模塊，即轉向配置子模塊101、轉向控制子模塊102與樁函數調用子模塊103，這三者共同地實現了一種在線補丁技術，即在不停機情況下，修改系統中某些函數的處理過程，以特定的新定義函數替代原有函數。這種函數替換技術在本發明中僅用於軟體調測。
需要說明，函數替換技術也就是補丁技術，現有技術中已提供了一些方法使用補丁技術用來修正已發行到市場的軟體BUG。在本發明中的補丁技術服務於市場發布前的調測，與現有技術中補丁技術的應用場合不同。本發明的補丁技術與現有技術中通用的補丁實現方法也不一樣，常規的補丁技術通常用jump語句絕對跳轉，而本發明是對函數調用棧進行處理，通過修改函數返回值來實現。
其中，轉向配置子模塊101用於設置如下信息1)哪些被測函數需要轉向；2)將要轉向至哪個目標函數，即測試專用函數；3)轉向控制的狀態標記，如激活、去激活等。
轉向配置是針對一個個的被測函數進行的。在本發明中，使用「轉向控制塊」(Transfer Control Block，TCB)來描述一個函數完成一次轉向所需的配置項。轉向控制表是多個轉向控制塊TCB的集合。轉向配置子模塊101管理轉向控制表。
轉向控制子模塊102包含如下功能1)分析主調函數(caller)與被調用函數(callee)；從當前調用棧遍歷最近各層函數調用的返回地址，由返回地址所處範圍結合轉向控制表中信息，分析出當前主調函數與被調函數。
例如，假定主調函數是caller_function，被調用函數是callee_function。在callee_function函數體執行前先調用轉向控制函數pseudo_call，調用次序為「caller_function-＞callee_function-＞pseudo_call」。此處，pseudo_call插在callee_function首部來執行，從邏輯上理解，pseudo_call屬於calee_function範圍，但不屬於callee_function的固有函數定義。在pseudo_call執行中遍歷當前調用棧，可獲知pseudo_call與callee_function調用後的返回地址。由於pseudo_call函數是按確定規則插裝的，所以可根據pseudo_call的返回地址推算出callee_function的入口地址。根據這個入口地址查詢「轉向控制表」，就可獲得callee_function的轉向控制塊(TCB)。另外，根據callee_function的返回地址查詢轉向控制表，一樣可獲得caller_function的TCB。
2)查詢當前調用棧獲取調用返回地址；3)控制當前調用轉向到測試專用函數；
4)將測試專用函數的調用結果返回給調用者；5)記錄調用覆蓋信息。通過分析出主調與被調函數，來記錄「主調-被調」函數對是否被覆蓋。
樁函數調用子模塊103主要實現測試專用函數的調用。即模擬函數調用的方式，先把參數壓棧，再調用測試專用函數。另外還需要先判斷當前樁是否激活，若激活就調用測試專用函數(即測試樁)。測試樁包括兩種形態預駐留函數與腳本函數，實現調用都是先把參數壓棧後調用函數地址。測試專用函數既包括測試中動態定義的腳本函數，也包括在被測系統中預先駐留的函數。在測試中，用戶可定義一個腳本函數，再對被測函數打樁，讓腳本函數替換被測函數來執行。而且，由於腳本函數支持在線更新，所以腳本打樁也支持測試樁邏輯在線更新。
為了實現函數調用轉向，首先在每個被測函數的首部插入一個轉向控制函數pseudo_call。如圖2所示，當主調函數caller_function調用callee_function時，callee_function中首條語句就是pseudo_call調用，pseudo_call是圖1中調用轉向模塊的主處理函數，其主要功能是實現調用控制轉向。
轉向控制函數pseudo_call可實現兩類返回跳轉，其一是替換方式跳轉，讓測試專用函數完全替代被調用函數，如圖2中實線A所標示，callee_function在首行pseudo_call調用後，立即返回到主調函數；其二是插入方式跳轉，如圖2中虛線B標示，pseudo_call執行後，被調函數的定義體仍被執行。在這種情況下，相當於測試專用函數插在被調函數之前運行了。這兩類返回跳轉所實現的腳本樁分別叫替換模式測試樁與插入模式測試樁。
為實現轉向控制，需要解決以下問題。
1.轉向控制函數的插裝把pseudo_call函數插入被測函數的首部，可採取四種方式1)藉助編譯器提供的插裝功能。
某些編譯器支持在函數調用前插入特定樁函數，例如Visual C/C++系列版本支持penter樁插入，使用編譯開關「/Gh」可做到這一點。
2)藉助符號跳轉表實現自動插裝某些程式語言的函數調用，是通過符號跳轉表實現的，比如在GCC中，調用某函數，實際是調用它在符號跳轉表的某地址，該地址再使用一個jmp絕對跳轉語句才跳轉到真正函數定義的位置。通過修改符號跳轉表即可插入pseudo_call函數調用。
3)藉助逗號表達式實現插裝例如在C語言中，已知某符號是函數，可以按以下方式插裝#define printf(pseudo_call，printf)使用逗號可連接多個表達式，運算時返回最後一個表達式的值。上例對printf函數做插裝，「printf」被替換成「(pseudo_call，printf)」，由於逗號運算的特點，語句「printf(「example」)」等效於「(pseudo_call，printf)(「example」)」，「ptr＝printf」等效於「ptr＝(pseudo_call，printf)」。
這種藉助逗號表達式與宏替換的插裝，既可以手工實現，也可以由調測工具自動實現。如本處舉例的printf宏替換語句可由工具自動生成，只要確定某符號是函數類型，不需知道它的原型就能實現插裝。
4)手工插裝也可以通過手工方式在被測函數首部插入pseudo_call函數。若為方便起見，定義一個宏指向pseudo_call調用，關閉這個宏(即取消該宏定義(undefine)，對應C語言的「#undef」指令)即取消插裝。例如在C語言中定義如下宏#define begin {pseudo_call；define end}在編碼時，需要一律以begin作為函數定義開始，以end作為函數定義結束。
以上四種方式中，第二種可以是動態、在線方式把pseudo_call函數插入，其它幾種方式是靜態的，在被測可執行程序生成之前就插入了。
2.轉向控制為實施測試，需要將特定的子函數調用轉向到測試專用函數(即測試樁)，為此需要執行轉向控制。
以C語言調用棧的組織特點為例。可以修改當前調用棧內的返回地址就實現轉向控制。例如函數A主調函數B時，先將主調函數B後要返回的地址壓棧，然後進入B函數執行。當B函數尚在運行中，如果把剛壓棧的返回地址改成另一函數C的地址值，那麼，函數B運行結束就不會返回到函數A，而是轉向到函數C。
圖2中caller_function調用callee_function，callee_function先調用pseudo_call，這兩次調用都先將返回地址壓棧。如圖3所示，在調用callee_function時(步驟302)，先將callee_function的返回地址RetAddr_of_callee壓棧(步驟301)。而在調用pseudo_call時(步驟304)，先將pseudo_call的返回地址RetAddr_of_Pseudo壓棧(步驟303)。在pseudo_call執行過程中，如果將調用棧中pseudo_call返回地址改為callee_function的返回地址，就導致callee_function定義體不被執行，相當於插入運行的pseudo_call函數替代callee_function運行了，這就是替換模式樁。
如果不修改棧中的返回地址，pseudo_call插在callee_function定義體之前運行，就是上文所述的插入模式樁。
3.查找轉向控制塊轉向控制表用於按地址值索引被測函數的轉向控制塊(TCB)，索引可以有兩類地址值，一是被測函數的入口地址，二是被測函數調用子函數時的返回地址。TCB中記錄的函數名稱、函數原型、函數所在源文件及行號、是否存在補丁函數、補丁函數類型(腳本/預駐留/未知)、補丁是否激活等信息，這些信息以及它對應函數的地址範圍可從以下渠道獲得1)從編譯器生成的調試資料庫中獲取，如VC的PDB文件，GCC的GDB信息記錄；2)從編譯過程文件中提取，如C語言的OBJ文件、Delphi語言的DCU文件等；3)從程式語言開發商提供的dump工具獲得。
由於打補丁了的被測函數經常在多線程環境下調用，這要求本發明的補丁機制要支持多線程環境，上面描述的TCB查表過程應採用某種互斥機制來保護操作安全。實現時主要保證TCB查表是多線程下安全的，即TCB內容可動態變化。如果要增刪補丁，或修改補丁的狀態，就得修改相應TCB內容，稱為TCB狀態維護。轉向操作過程中要獲取並使用相應的TCB，其過程要與TCB狀態維護操作互斥。該互斥按常規的方法實現即可。
下面將參考圖4描述在根據本發明的一個實施方式中對一個被測函數啟用腳本補丁、實現調用轉向，以及調用結束後關閉補丁的操作過程。
圖4左側4個步驟是概要處理過程，右側是概要步驟的第3步「發起測試」的分解過程。
在步驟401，針對被測函數設置腳本形式的補丁函數，即填寫相應TCB表，表中記錄某函數對應某補丁。接著激活該腳本補丁(步驟402)。在腳本補丁被激活後，就可以發起測試，(即運行被測函數，步驟403)。
在步驟403中，首先，進入被測的主調函數caller(步驟4031)，主調函數caller調用被調用函數callee(步驟4032)。之後，進入轉向控制函數pseudo_call(步驟4033)，分析出主調函數與被調用函數(步驟4034)。
接下來，判斷是否已定義了腳本補丁且該腳本補丁被激活(步驟4035)。如果是，則設置調用返回的轉向地址(步驟4036)，然後調用腳本函數，並傳遞腳本調用的返回值(步驟4037)。否則，從pseudo_call直接返回(步驟4038)，完成callee函數調用，並傳遞該函數返回值(步驟4039)。
在步驟4036或4039傳遞了調用返回值後，返回到caller函數繼續執行(步驟4040)，完成被測函數caller調用。
最後，刪除或去激活該腳本補丁(步驟404)。
圖4操作流程是針對補丁函數是腳本函數的情況，如果補丁函數是被測系統中的預先駐留的函數時，整體流程類似，僅有如下差別1)設置補丁函數時指向預駐留函數，而不是腳本函數；2)判斷補丁是否激活之後運行補丁函數時，是調用預駐留函數，而不是腳本函數。
4.自擴展調試器在轉向控制函數pseudo_call執行中，可識別主調用caller函數與被調callee函數。利用此特性，本發明可在pseudo_call函數構造支持單步跟蹤的調試機制，本發明要求這個自擴展的調試器基本等效於常規開發語言的單步跟蹤機制，即提供諸如設置斷點、單步跟蹤、查看變量、修改變量等主要調試功能。
自擴展調試機制在用戶應用代碼層次實現。該機制不依賴於常規調試器所採用的中斷方式實現。所以，本調試器與程式語言自帶調試器是可兼容並存的，兩者能同時使用。而且，兩者可以隨時、在線進行切換，切換不必重起被測系統。不必重啟被測系統是因為兩者機理上不衝突，上述自擴展調試器實際等效於用戶自己寫的程序(其操作界面在使用時象調試器)，它的工作原理與編譯器自帶的調試器不衝突。這一點在測試工具實施時比較有利，因為編譯器自帶的調試器功能更為全面(比如能看彙編代碼、能讀寫寄存器等)，本發明的自行擴展的調試器就不需面面俱到地實現編譯器自帶的每一項功能，採用在線切換可降低自擴展調試器因功能不足而帶來的負面影響。
具體而言，在執行每個被測函數首部的pseudo_call函數時，先分析出主調函數與被調用函數，從被調函數的TCB中獲得當前函數所在的源文件與行號，此時若當前處於斷點狀態，pseudo_call將等待用戶輸入下一步跟蹤指令，比如函數內單步(Step)、跟入下一級函數(StepIn)、跟出當前函數(StepOut)等、繼續執行直到下一斷點(Run)，pseudo_call根據不同指令對行號棧做不同操作。
在本發明中，設計一個「行號棧」來保存單步跟蹤中歷史行號的位置，以便函數單步跟出時，能準確識別上級函數，並能跳回到歷史跟入的位置。例如，在函數1調用函數2、函數2中又調用函數3時，針對行號信息的壓棧與出棧過程如圖5所示。其中，出棧過程表示函數3調用結束並返回至函數2、函數2調用結束並返回至函數1、直至函數1結束操作返回上一級函數時的行號棧的變化過程。本領域技術人員可以理解，所述棧是典型的先入後出的數據結構。
如果跟蹤指令是「繼續執行到下一斷點」，也由執行路徑上各函數的pseudo_call函數識別出當前函數有無斷點，若有斷點再分析斷點條件是否滿足，若斷點條件滿足就自動進入交互式單步狀態。
本發明的自擴展調試器還可支持在斷點調試中用測試腳本存取被測系統中的變量，包括全局變量與局部變量，以及用腳本發起被測函數調用。腳本化的變量存取與函數調用可採用一種語言映射技術實現。下面將具體說明這種映射。
圖6顯示了腳本解釋器驅動的實現在線測試系統的框架結構。如圖所示，測試主機1包含測試外殼(Test Shell)11，用於發起調測命令，以及提供開發、測試的平臺。測試主機端可以採用個人桌面系統(如Windows、Linux等)。測試外殼11可以是其中的一個可執行程序。
目標機2(即被測系統)通常是被測單板，或者是一個仿真程序。目標機2中駐留有測試代理(Test Agent)模塊21。該測試代理模塊21可以是一個腳本語言系統。在本發明中，對腳本語言的種類並沒有限定，只要能滿足本發明規定的映射規則即可。在目標機2的測試代理模塊21內包含有被測試程序的符號表和類型表。關於符號表和類型表將在後文中說明。
測試主機1的測試外殼11與測試代理模塊21具有通信連接。此連接的通信方式可以是共享內存通信(對於目標機與測試主機共用同一臺計算機的情況、TCP/IP通信，或是其它如串口通信等形式。
如圖7所示，測試代理模塊21包括腳本系統211和通訊單元212。通訊單元212負責處理測試代理模塊21與測試主機1的測試外殼11的上述通信連接。
腳本系統211包括內嵌調測支持模塊2111和映射支持模塊2112。內嵌調測支持模塊2111是常規的調測應用編程接口(API)的集合，提供諸如復位目標機、啟動或停止某任務、設置斷點、刪除斷點等功能。映射支持模塊2112用於實現被測系統中的C語言變量與函數向腳本系統映射的功能。在完成映射後，腳本系統211中生成與C語言的變量和函數同名的映射變量與映射函數。
為了實現本發明的目的，要求測試主機1和目標機2都應該有對腳本文件的處理能力。為此，測試主機1的測試外殼11中包含了一個命令行編輯輸入單元以及命令解釋模塊(未示出)，命令行編輯輸入單元用於支持用戶輸入腳本文件格式的調測命令，命令解釋模塊把輸入的調測命令轉化為能夠由測試代理模塊21中的腳本解釋器解釋執行的測試命令，並傳送給目標機2的測試代理模塊21。測試代理模塊21中相應地包含一個腳本解釋器(未圖示)，用於實現測試控制。腳本解釋器接收命令解釋模塊傳送來的測試命令，對該命令進行解釋並實施相應動作。實際傳遞的格式是中間碼格式，類似Java虛擬機解釋字節碼命令一樣，這個中間碼格式也稱偽編解碼。
當目標機2執行測試並反饋結果、或在測試過程中發出了列印信息，測試主機1的測試外殼11將會接收該結果或信息並進行處理。
參見圖8，首先，目標機2要進行初始化處理。當測試主機1啟動命令解釋模塊的程序時，目標機2啟動被測程序(S501)。然後，目標機2初始化其中包含的腳本系統211，包括設置測試代理模塊21的相關配置(S502)。在此過程中，測試代理模塊21的表生成單元(未示出)從目標機2被測試的軟體在其最後一次編譯後生成的GDB或PDB調試資料庫中提取與被映射的變量/函數相關的信息，生成符號表和類型表(後文將要說明)，並記錄在測試代理模塊21中(S503)。然後，測試代理模塊21的腳本系統211把符號表及類型表映射到一個全局的變量容器(S504)。按照預定的腳本把類型表、符號表的符號都映射至變量容器中(S505)。該操作將被測程序中的變量與函數在腳本系統中描述為映射對象(即腳本的TData類對象)。由於轉換全部符號會導致CPU與內存資源浪費，因此根據本發明的一個實施方式，不對符號作一次性全部轉換，而僅根據測試需要來映射。例如，運行測試腳本時，腳本包含哪些映射的變量與函數，就動態轉換那些變量或函數，或者由用戶自行確定規則來按需轉換，比如所有外部定義的符號都不作映射。
此後，進行被測系統的正常測試(S506)。在測試主機1，用戶使用類似C語言的腳本文件對傳送來的編碼進行操作。測試外殼11中的命令解釋模塊解釋用戶的輸入，並發出相應的測試指令。該命令被傳送到測試目標機2，並在其腳本系統211中運行，從而得到按編碼邏輯所得到的測試運行結果。這個測試運行結果可被反饋到測試主機1，並顯示給用戶。在上述方法中，由於可以在線地編寫測試腳本，直觀地查看或修改被測變量、調用被測函數，所見即所得，可以馬上看到測試結果，也可馬上改進測試，從而提高了測試的效率。
因為C語言編碼對其數據的結構/類型要求很嚴格，作為它的映射後的腳本，必須能夠支持基本的C編程的功能和要求。
為了實現上述對C語言編碼的映射，根據本發明，在目標機2的測試代理模塊21中駐留了被測試程序的符號表和數據類型表。這兩個表將直接支持本發明規定的映射規則的實現。本發明的映射方法依賴於對目標機系統的各種符號及其類型信息的收集與分析。調試資料庫在編譯過程中由編譯器產生，例如Visual C/C++編譯過程中會產生PDB文件，GCC在編譯時也將GDB調試信息編譯到目標程序中。如上所述，這些信息可在編譯過程中由編譯器產生的調試資料庫中提取，根據所提取的信息相應生成符號表和類型表。
不同的C編譯器生成的調試資料庫格式並不一樣。本發明通過對類型表和符號表的生成達到了對不同格式的統一。類型表記錄被測系統定義過的各種類型。這些類型必須包括主類型信息、子類型信息、以及佔用字節數。表1是類型定義格式的示例表1
同時要確保類型表下各欄目具有唯一性，即，由相同的主類型與子類型以及佔相同字節數而構成的類型項只能存在一個。
符號表記錄變量或函數的地址值及其類型ID。其中符號地址有兩種形式，既可以記錄絕對地址，也可以記錄相對地址。例如，存取函數內局部變量或傳入參數時，則使用相對於當前棧頂位置的偏移值。再如，某變量在另一變量空間下存在，其地址也按該另一變量的地址加上一個偏移來表達。
符號來源有兩種方式，一是來源於另一映射對象，二是來源於某絕對地址。後者是描述變量或函數的常規方式，前者常在將同一內存空間看作多種類型的變量進行操作時使用，例如強制類型轉換，是將某字串數組的某一偏移看成整數類型變量。
在生成了符號表和類型表之後，為了腳本的操作方便，系統要定義與表中數據相應的轉化腳本類對象，即TType類對象對應於類型表，TData類對象對應於符號表。在TType類對象定義的實例化數據要包含如下信息該類型唯一的標識，類型主類別信息，類型子類別信息，類型大小。各個符號映射為TData類定義的實例化數據，要包含以下信息該符號對應的類型ID，符號的來源，相對於來源的偏址，是否是自動釋放內存。
表格內容的映射按圖6進行。首先，腳本系統211從符號表裡找出需要的符號(包括變量和函數)信息，如符號名稱，符號的類型ID及符號地址(步驟901)。然後腳本系統211通過該類型ID查找相應的類型是否有生成的TType類對象，若沒有則創建該TType類對象，即通過定義TData或TType類對象，調用類定義的建構函數來創建這個類對象的實例(步驟902)。最後，根據該符號的來源、所屬的TType對象、地址偏移及是否自動釋放內存等信息創建被映射符號的TData類對象(步驟903)。
在創建的映射實例包括映射變量與映射函數時，首先要有相應的TType對象指明類型信息。當類型表中的各項都轉化成TType類實例後，原有類型信息表不再有用，其佔用的資源可釋放，而用新生成的各個TType類實例組成一個新表，即TType類型表。映射變量與映射函數都是TData類實例。如圖7所示，每個TData類實例使用該符號對應的類型ID(Data type)指示它使用TType類型表中的哪個類型。
需要注意，TType類的對象可能是嵌套引用的。某些複合類型如struct/union/指針等包含了子類型，而且同一子類型可能被多個複合類型引用。所以，在創建每個TType對象時，該類型涉及的其它類型也同時被創建。
由於測試主機和目標機的系統資源是有限的，為了更有效地進行測試，在相應時期對使用資源的處理是十分重要的。根據本發明，為了有效利用系統資源，變量、函數、類對象等在腳本語言中作為一個實體存在，實現了生存周期自動管理。這些實體所佔用的資源會自動申請、自動釋放。映射數據作為腳本類對象，也支持它所涉及資源的自動申請與釋放。
例如，腳本系統21要創建一個映射變量buff，它是一個長度為24位元組的字串數組，這時腳本系統21會向目標機2自動申請它佔用的內存，包括buff變量作為腳本TData類實例要佔用的內存空間，以及字串數組的24位元組空間。為描述方便，在本發明中，將前一類空間稱為腳本實例空間，將後一類空間稱為C實例空間。當新創建的映射變量的生存周期結束時，這兩種空間都將被自動釋放。
但是，由於編程的複雜性，腳本實例空間與C實例空間並不總是同時申請或同時釋放的。例如對於被測系統的全局變量，其佔用空間是靜態分配的，全局變量的映射實例在生存周期結束時，應只釋放腳本實例空間，而不應釋放C實例空間。再如，使用腳本文件中創建一個映射變量a後，這個變量的腳本實例空間與C實例空間應同時申請或釋放。但是，如果把這個映射變量a看成另一類型的映射變量b，例如C語言中的強制類型轉換時，將同一地址空間下某變量，看成另一類型的變量，則創建變量b時應新申請腳本實例空間，但不應重複申請C實例空間。另外，當變量a或變量b被刪除時，不管先刪除哪一個，都應保證尚在使用的另一個變量所操作的C實例空間還有效。也即C實例空間可被多個映射變量共享，只有該C實例空間所全部涉及的映射變量都釋放了，這個C實例空間才自動被釋放。此外，映射變量使用的C實例空間還需配合測試，必要情況下可修改其中的標誌。例如為映射變量設置Autofree屬性，該屬性為TRUE表示該映射變量的C實例空間是隨它的腳本實例空間釋放而釋放的，否則屬性取值為FALSE，表示C實例空間不隨腳本實例空間釋放而釋放。
為實現上述目的，根據本發明的一個實施方式，對映射實例設置了3個屬性。圖8顯示了映射實例的一個示例。如圖8所示，該屬性包括是否自動釋放內存(Autofree)、符號來源(Owner)、相對於來源的偏移地址(Offset)。其中「是否自動釋放內存」的屬性用於指示該映射變量的C實例空間是否跟隨腳本實例空間一起釋放。「符號來源」用於指示該映射實例的歸屬對象，其取值既可以是某絕對地址值，也可以是另一個映射實例。相對於來源的偏移地址用於指示本映射實例所用C實例空間的起始地址相對於其符號來源指示的空間地址的偏移量是多少。由於腳本語言具備生存周期自動管理特性，所以如果使符號來源屬性指示另一映射實例，就實現了同一C實例空間被多個映射實例共用時也能夠實現資源的自動管理。
在這些初始階段的步驟完成後，系統還要生成一個全局的變量容器。該全局變量容器用於包含所有的變量和函數，並將它們置於統一的平臺下。變量容器能捕獲針對該實例的屬性取值與賦值的操作，並根據特定情況進行操作轉義。容器本質上也是腳本的類對象，只不過存取它的屬性時，系統會做特定的截獲處理。
例如，參考下式定義的變量容器vc＝newVarContainer；vc.Var3＝MapString(「Another string」)；vc.Var3＝「Change value」；vc.Var4＝MapString(「It is example！」)；vc.Var4＝vc.Var3；在這個例子中，第3行和最後一行分別是針對Var3的賦值和取值，最後一行是按照C語言風格描述的。為實現這一點，變量容器下的映射變量的取值和賦值將進行轉義，如下兩條語句vc.Var3＝「Change value」；vc.Var4＝vc.Var3；等同於vc.Var3.setValue(「Change value」)；vc.Var4.setValue(vc.Var3.getValue)；可以看到，vc.Var3＝「Change value」是合乎C風格的賦值，而vc.Var3.setValue(「Change value」)是調用，不是賦值，遠離C風格了。
為支持轉義，腳本語言本身的類方法操作要支持定向功能，定向後使用賦值語句最終執行這個調用語句(vc.Var3.setValue(「Change value」))。
變量容器除支持以上取值與賦值轉義外，還要支持按腳本方式的變量賦值，即用指定的值代替變量原有值，而不管原有值是不是映射變量。例如vc.Var4＝MapString(」It is example！」)；setVcValue(vc，「Var4」，「Another string」)；在這個例子中，第一條語句在變量容器下創建字串映射變量Var4，第二條語句將這個Var4替換成腳本的字串值。該句執行後，Var4不再是映射變量了，而是像常規腳本變量那樣賦值，其類型是動態變化的。為此，本發明要求提供用於動態賦值的API函數(類似於本例的setVcValue)。
變量容器的使用對於函數的調用也是重要的。例如，要實現cdecl與stdcall調用，在TData類中定義添加callCdecl與callStdcall兩個方法，在腳本中按如下方式調用C函數vc.result1＝vc.func1.callCdecl(IntType，3，「example」)；vc.result2＝vc.func2.callStdcall(CharType，『A』，『B』)；這兩個方法都要求用第一個參數指明該調用的返回值類型，其它參數依次是完成本次C調用的各參數值。由這兩個方法發起調用沒有基於一種函數原型，使用有點麻煩，因為調用時要指定返回值類型，而且各傳入參數的類型是否匹配、參數個數是否正確都無法檢查。為改進這一點，在本發明中對TData添加了對_call_調用的支持，其使用方法如下vc.result1＝vc.func1._call_(3，「example」)；
vc.result2＝vc.func2._call_(『A』，『B』)；為了讓描述方法更簡單，本發明定義腳本類的支持內嵌call轉向功能，從而把上面的腳本改寫成如下方式vc.result1＝vc.func1(3，「example」)；vc.result2＝vc.func2(『A』，『B』)；改寫後執行效果是等同的，即當類對象自身作為函數去調用時，系統自動將它轉向到該對象的_call_方法。一些現有的腳本語言，如Python與CSE可支持這種轉向。本發明藉助該機制實現新的應用，即，讓映射函數(是腳本實例)調用與C語言在表達上保持一致，如vc.func._call_(3，「example」)未保持一致，而vc.func(3，「example」)是一致的。至此，使用腳本調用C函數的風格就與C語言風格一致了。
除了上述常規的cdecl與stdcall固定參數類型的調用，本發明還需要支持cdecl風格的變長參數調用，例如變長參數函數MyPrint的原型為「void MyPrint(char*format，…)」，根據本發明，可以按如下方式調用它vc.result＝vc.MyPrint.callCdecl(「name％s」，「george」)；在此，變長參數調用要在C函數調用發起前，按參數傳入值組裝成壓棧數據。然後模擬C語言調用，獲取模擬調用的返回值。
如果映射函數有返回值，則調用映射函數應返回一個映射變量。即原C函數的返回類型不為void時，取它的類型及返回的數值，生成映射變量。
在本發明中，調試操作中修改被測變量、與調用被測函數，可以通過上述調測系統中的語言映射技術實現。
另外，藉助上述語言映射技術還可實現模擬被測代碼的功能，即，腳本化地存取被測變量與調用被測函數。該功能在自擴展調試器中用於設置條件斷點，用一個腳本表達式描述斷點條件，只有條件滿足程序才會在斷點位置停住。
由於本調試機制依賴於在函數首部插入pseudo_call，必然導致單步跟蹤只在函數調用的時候才起作用，無函數調用的語句，比如C語言的if、while、switch等控制語句的位置無法在單步跟蹤時停住。針對這一情況，根據本發明，把這些非函數調用的語句轉化成函數調用，通常使用逗號表達式的插裝方式做轉化，如下#define if(expr) if(pseudo_call，expr)#define while(expr)while(pseudo_call，expr)這樣，由於被測函數的所有控制語句(比如C語言中的if、else、while、for、switch等)與函數調用都支持單步跟蹤，並且全局變量與各函數的局部變量都可讀寫、被測函數可調用，因而自擴展調試器的功能就比較完整，而且，也實現了調試過程的腳本化控制。
5.將調試過程轉換成腳本描述調試過程比較隨意，如果把每一個單步跟蹤過程都轉化為測試腳本，必然導致自動生成的用例可維護性很差，為解決這個問題，本發明遵循第4代白盒測試方法的相關要求，實施灰盒方式測試。
灰盒方式是把被測對象(即被測函數)作為一個整體，測試針對它的外在接口，即被測函數的傳入參數、返回值，以及該被測函數涉及的全局變量。該灰盒方式是一種粗粒度調試，基於函數接口而非函數實現過程，保證測試描述既不過於瑣碎，也相對穩定，不必每次代碼修改就要調整用例。
前文敘述的調試過程實現了腳本化描述，現在為了將這種描述轉化成規範用例，還需要取其子集，只將粗粒度的、基於接口的操作轉化成測試腳本。在本發明中，將能轉化成自動用例的調試操作稱為檢視操作。檢視屬於調試的子集。
檢視操作(灰盒測試)包括如下步驟1.通過查看或修改全局變量，或調用被測系統中的函數來構造測試運行環境；2.調用被測函數發起測試；3.在被測函數的首部設置斷點，可指定斷點條件，單步跟蹤到該位置時，可用測試腳本查看與修改傳入的參數與全局變量。其它被測函數也可以用測試腳本發起調用；4.單步跟蹤時可以在函數尾部停住。此時，函數返回值與全局變量可以用腳本查看與修改，其它被測函數也可以用測試腳本發起調用。
將檢視記錄轉化為測試腳本(用例)時，應滿足以下要求1.在一次調試的任意檢視操作步驟中，可使用斷言(如assert語句)判斷運行情況是否與期望值相符。在本發明中，其操作過程能夠被記錄下來的調試被稱為「檢視」。檢視操作類似於調試操作，可以象調試一樣進行單步跟蹤，單步跟蹤過程中可運行斷言語句，例如assert(AValue＝＝BValue)，這種斷言直接服務於測試。
2.調試中在用戶操作界面可查看當前範圍的各個變量取值，支持選中某些變量，自動按當前取值生成測試斷言。用戶可以觀察當前各個全局變量的取值，如果希望把某幾個變量的取值自動生成結果進行判斷，選中這幾個變量後再在界面按某個快捷鍵，即能夠自動生成結果判斷語句，比如assert(AValue＝＝5)。
3.當運行斷點處於函數的首部與尾部時，用戶在操作界面可選擇是否將調試操作記錄為測試腳本，即用戶可自行決定某些調試操作(如查看變量、修改變量、調用函數)生成到自動用例中，而另一些不必納入到自動用例中。例如當前檢視在函數首部停住，如果這個函數傳入參數iValue取值為5，則可以在變量查看列表中選中這個變量，之後在檢視操作結果後可自動生成相應的assert語句，例如assert(iValue＝＝5)。
4.一次調試後生成的測試用例腳本，還可以按手工方式進行調整。調整內容可包括用戶可以手工修改這種自動生成的腳本，如上例「assert(iValue＝＝5)」，用戶可把它改為「assert(iValue＝＝6)」。
6.測試程度評估在轉向控制函數pseudo_call中能分析出被測系統中每次調用的主調函數與被調用函數，依據這個特性，可以通過分析測試用例對函數中調用的覆蓋程度來評估對每個函數的測試程度。
例如，被測函數共有10項子函數調用，如果測試只覆蓋了一、兩項調用，說明設計的測試用例是不夠的。如果10項中有9項或全部調用都被覆蓋到了，則說明當前測試很充分了。
在pseudo_call函數中增加調用信息記錄，就可實現一種調用覆蓋率統計，即統計測試中已覆蓋到的調用個數佔被測試函數總調用個數的比例。調用覆蓋率實際等效於通常白盒測試工具所支持的語句覆蓋。
通過將問號表達式與宏替換組合，可以進一步實現分支覆蓋統計。例如在C語言中定義如下宏#define if(expr) if(expr)？if_1if_0)#define while(expr)while((expr)？while_1while_0)在if判斷中，如果判斷條件為TRUE，則執行插裝函數if_1，反之執行if_0。在while循環判斷中，如果判斷條件為TRUE，則執行插裝函數while_1，反之執行while_0。這兩種情況實現了C語言的if與while的分支記錄，其它分支語句處理過程類似。在其它程式語言中，藉助and與or的短路判斷也能實現類似的分支插裝。
基於調用的覆蓋率評估還可以支持客戶化的評估定製。在某些情況下，特定的函數調用(例如出錯處理函數、非測試關注函數等)不影響測試程度評估，可以將這些特定函數登記到忽略函數表中。在pseudo_call執行中分析出被調函數後，查詢忽略函數表判斷該被調函數是否該被忽略。若忽略就不納入覆蓋率統計。這種可定製的評估機制，可保障軟體研發過程能持續、平穩地以可控的質量向前推進。
本發明適用於軟體開發領域，主要針對C語言(但不限於C語言)開發環境的軟體調試與測試。
權利要求
1.程序調測系統，包括測試主機和目標機，所述測試主機對所述目標機的程序進行調試和/或測試，其中，所述目標機中包含調用轉向模塊，所述調用轉向模塊包括轉向配置子模塊，配置被測試程序的被測函數進行一次轉向所需的配置項，所述配置項包含在所述轉向控制表中；轉向控制子模塊，識別主調函數與被調用函數，並根據所述轉向控制表中相應的配置項，控制主調函數的當前調用轉向到測試專用函數；和樁函數調用子模塊，根據轉向控制子模塊的當前調用轉向控制，調用相應的測試專用函數以提供對被測函數的測試。
2.根據權利要求1所述的程序調測系統，其中，所述轉向控制表中包含多個轉向控制塊，每個轉向控制塊記錄一個被測函數的信息，包括函數名稱、函數原型、函數所在源文件及行號、是否存在補丁函數、補丁函數類型、補丁激活狀態標誌；並且所述轉向控制塊的信息來源於調試資料庫，或編譯產生的過程文件，或相關dump工具。
3.根據權利要求1所述的程序調測系統，進一步包括自擴展調試子模塊，用於在用戶代碼層次實現斷點調試，所述調試採用腳本語言描述，並利用行號棧實現單步跟蹤中的前後步定位；其中，對於C語言程序，利用逗號表達式在if、while、或switch控制語句中插裝轉向控制函數，從而實現針對這些控制語句的單步跟蹤。
4.根據權利要求1所述的程序調測系統，進一步包括測試程度評估單元，通過分析測試用例對函數中調用的覆蓋程度來評估對每個所述被測函數的測試程度，所述評估包括使用問號表達式、宏替換、與或短路的方法之一或其組合進行分支覆蓋率統計；以及在轉向控制函數中分析被調用函數，結合忽略函數表實現測試評估標準的定製。
5.一種程序調測方法，包括以下步驟配置被測試程序的被測函數進行一次轉向所需的配置項；分析主調函數與被調用函數，根據被測函數的所述轉向的配置項，控制主調函數的當前調用轉向到測試專用函數；和根據轉向控制子模塊的當前調用轉向控制，調用相應的測試專用函數進行測試。
6.根據權利要求5所述的方法，其中所述控制主調函數的當前調用轉向到測試專用函數包括在每個被測函數的首部插入轉向控制函數的步驟，並且所述轉向控制函數採用以下方式中的任一種進行所述轉向控制函數的插入1)藉助編譯器提供的插裝功能實現插裝；2)藉助符號跳轉功能實現插裝；3)在C語言中藉助逗號表達式實現插裝；4)手工方式插裝。
7.根據權利要求6所述的方法，其中所述轉向控制函數按如下步驟實現轉向1)判斷所述被測函數是否已定義了測試專用函數；2)若已定義了測試專用函數，則確定所述測試專用函數是否處於被激活狀態；3)若所述補丁函數的狀態為已激活，則通過修改調用棧中的函數返回地址值實現轉向。
8.根據權利要求7所述的方法，其中轉向控制函數利用轉向控制表來實現轉向，並且所述分析主調函數與被調用函數的步驟包括1-1)從所述調用棧中提取最近兩個函數調用的返回地址；1-2)根據返回地址查詢所述轉向控制表，獲得所述主調函數與被調用函數的轉向控制塊。
9.根據權利要求5-8任一項所述的方法，其中所述測試操作包括通過查看或修改全局變量，或調用被測系統中的函數來構造測試運行環境；調用被測函數發起測試；在被測函數的首部設置斷點，在單步跟蹤到該斷點時，用測試腳本查看和修改傳入的參數與全局變量，或調用其它函數；和單步跟蹤到函數尾部時，用所述測試腳本查看和修改函數返回值與全局變量，或調用其它函數。
10.根據權利要求9所述的方法，進一步包括從調試操作生成測試腳本，所述生成測試腳本滿足以下要求1)在一次調試的任意檢視操作步驟中，能夠使用測試斷言判斷運行情況是否與期望值相符；2)在調試中，支持在用戶操作界面查看當前範圍的各個變量取值，當某些變量被選中時，自動按當前取值生成所述測試斷言；3)當運行斷點處於函數的首部與尾部時，用戶能夠有選擇地將調試操作記錄為測試腳本，所述調試操作包括查看變量、修改變量、調用函數；以及4)在一次調試後生成的測試腳本中，能夠以手工方式進行調整。
全文摘要
本發明提供了一種程序測試系統及方法，用以提高程序測試效率。該方法包括配置被測試程序的被測函數完成一次轉向所需的配置項；識別主調函數與被調用函數，控制主調函數的當前調用轉向到測試專用函數；和根據轉向控制子模塊的當前調用轉向控制，調用相應的測試專用函數進行測試。本發明還支持基於函數調用的、可定製標準的測試評估方式。本發明有助於軟體研發中，特別是C語言項目研發中，大幅提升調測的工作效率，提高測試操作易用性，並有助於測試質量提升。
文檔編號G06F11/36GK1949187SQ20061014519
公開日2007年4月18日 申請日期2006年11月17日 優先權日2006年11月17日
發明者曹修洪 申請人:深圳市領測科技有限公司