袁博文,張 威,皇甫睿帥,袁 聰
(1.陸軍裝甲兵學院 信息通信系,北京 100072;2.湖南省軍區 數據信息室,長沙 410000;3.中國人民解放軍95852部隊,海南 東方 572600)
軟件系統在社會各個領域的作用日益重要,人們對軟件系統的要求也日益增高,軟件質量首當其沖。盡管存在代碼審查、形式化驗證等輔助手段,但軟件測試依然是目前最主要的軟件質量保障手段[1]。而軟件測試方法與測試數據是軟件測試過程中重要組成部分。為了提高測試工作效率,選擇合適的方法顯得十分重要。單錦輝等[2]提出一種由故障檢測、故障定位、故障排除、交付等組成的集成化的軟件故障診斷過程框架。同時,將智能算法運用到測試用例自動生成上已經有了一些研究。劉龍霞等[3-4]將分類樹,貪心算法,遺傳-蟻群混合算法等運用到了測試數據自動生成中。
Windows Hook (即Windows鉤子)是Win32系統中用于監視、截獲或重定向發往目標窗口消息的特殊接口[5],該接口常常用于軟件錄制回放。Windows 系統的異常處理機制除了能夠幫助軟件開發人員發現和解決軟件中的錯誤外,被廣泛應用于軟件保護技術、軟件漏洞利用等方面[6]。在經過用戶同意的前提條件下,利用Hook接口記錄用戶軟件應用數據,同時利用Windows系統結構化異常處理機制對軟件進行故障識別。并且生成相對應的測試用例以實現相應的故障重現。有針對性的測試用例能為軟件發布后期測試與維護提供有效的幫助,降低測試成本。所以,對于軟件運行過程中應用數據的監測處理研究具有相當重要的現實意義。
本系統主要分為兩個功能模塊實現:用戶操作監測模塊;軟件故障識別模塊。系統功能框圖如圖1所示。用戶操作監測模塊和軟件故障識別模塊分別監測用戶操作和待測軟件狀態,并將結果和軟件故障時錯誤報告一起記錄下來。根據記錄的結果生成測試用例。

圖1 系統功能框圖
該模塊主要功能為記錄用戶對被監測軟件的操作。軟件測試人員在對軟件進行黑盒測試時,往往采用大量測試用例對軟件進行測試,以達到更高的測試覆蓋率,因此測試用例的設計成為了提高測試效率關鍵點。Windows本身是事件驅動的,而消息就是為了描述事件特征而產生的格式化信息。消息產生后被追加到消息隊列中,并被分發到對應的應用程序窗口進行處理。如果能將在應用程序窗口處理消息之前,先截獲有用的消息,從中取出需要的數據,便能實現對待測軟件進行用戶操作監測。同時,為了不影響待測軟件的自身正常運行,將需要的數據從消息取出后,應將消息完整的傳遞給原目標窗口。
基于本模塊需求,選擇利用Windows系統提供Hook消息處理機制實現。Hook根據處理消息分為許多種類,同時又分為全局與局部。全局 Hook可以監視系統范圍的消息,而局部 Hook只能監視本程序的消息。本模塊在實現過程中用到的Hook包括WH_CALLWNDPROC、WH_KEYBOARD、WH_MSGFILTER,其類型與作用如表1所示。
本模塊預先將鉤子程序封裝在動態鏈接庫文件中,并預留待測軟件進程號接口。為實現目標軟件監測,本模塊設計在進行監測之前提供系統運行所有進程名與其對應的進程號于列表框中,用于監測軟件的選定。當選擇需要監測的軟件之后,本模塊調用鉤子函數,將鉤子注入到目標軟件中。由于用戶對于軟件有效操作主要包括菜單操作,對話框操作,字符串輸入操作等,結合Hook機制特點,本模塊識別并記錄的信息有:被點擊菜單名(包括多級菜單);菜單項關閉;對話框中被點擊的按鍵名;對話框中文本框內容變化;對話框中文本輸入。

表1 用戶操作監測模塊使用的Hook
將用戶操作依次按照上述方式記錄,生成用戶操作序列。因此用戶操作的再實現將變得十分簡單,也為軟件后期測試與升級提供了測試用例的來源。本模塊流程框圖如圖2。

圖2 用戶操作監測模塊流程框圖
該模塊主要功能為識別待監測軟件故障。本模塊是基于Windows系統結構化異常處理機制(Structure Exception Handler,SEH)。當異常發生時,軟件會向系統拋出異常,請求系統對異常進行處理。而Windows系統允許嵌套式異常處理機制的存在,即當異常發生時,操作系統的異常分發函數在進行處理后,如果異常沒有被處理就會遍歷異常處理鏈,直到異常被處理,如果仍沒有注冊函數處理異常,則將異常交缺省處理函數或者直接結束產生異常的進程[6]?;诖?,本模塊設計一個異常處理函數與鉤子程序一起封裝成動態鏈接庫。當待監測軟件發生異常時會調用異常處理函數,而此時堆棧中為 EXCEPTION_REGISTRATION結構體將會保存本次異常的錯誤信息。本模塊通過記錄錯誤信息實現故障的識別,錯誤信息中部分異常代碼含義如表2所示。

表2 錯誤信息中部分異常代碼含義
同時Windows系統自身會將軟件異常信息記錄并發送到微軟公司服務器,但系統用戶只能通過錯誤報告窗口查看部分錯誤信息。為了能更加深入的了解故障信息,更好的幫助解決錯誤,通過自編軟件記錄顯然是更好的選擇。設計一個簡單程序窗口,該窗口能通過用戶輸入一元二次方程等式,自動計算出等式解。當該軟件發生故障時,可通過錯誤報告窗口查看相關錯誤信息,如圖3所示。

圖3 軟件問題報告窗口
當用戶運行目標程序的同時運行監測程序,即可開始實現軟件應用數據的提取。具體步驟如下:
步驟1:監測軟件開始運行,選擇需要監測的進程名或者進程號;
步驟2:創建記錄文件;
步驟3:將鉤子程序與異常處理程序掛入系統,監測目標軟件;
步驟4:當目標軟件正常運行時記錄目標軟件操作信息,當目標軟件發生異常時記錄異常信息;
步驟5:重復步驟4,直到目標進程終止;
步驟6:重復步驟1,直到監測軟件關閉。監測程序流程框圖如圖4。

圖4 監測程序流程框圖
軟件運行過程中的數據與不正常停止后產生的錯誤報告對于軟件后期維護與升級具有重要的作用。在Windows系統的運行過程中,某個程序出現非法操作或錯誤提示是每個用戶都會遇到的情況。而此時,Windows會啟動錯誤報告機制(Windows Error Reporting,簡稱WER),詢問用戶是否發送錯誤信息到微軟公司,同時程序將停止運行。
當程序出現非法操作或者錯誤提示時,程序會向系統拋出異常消息。監測系統通過捕獲軟件拋出的異常消息,判定軟件出現異常。而后監控系統會調用EXCEPTION_RECORD結構中ExceptionInformation成員進行二次識別。由于Windows錯誤報告機制為當錯誤發生之后會立即產生許多有效的數據報告并將報告上傳至后臺服務器,而后將大部分數據報告刪除,所以為了獲得盡量多的數據,當系統發生故障時,應盡快將錯誤報告備份。基于此,當識別出目標軟件發生故障之后,監測系統應立即軟件錯誤報告中的信息提取備份,作為后期分析數據。
用戶在對平臺進行操作時會產生大量操作數據,而與被監測軟件相關的操作往往都是在同一窗口下的。軟件測試人員在獲取測試數據后,結合錯誤報告與操作記錄,經過數次反向實驗便能確定用戶操作中的有效部分,進而生成能夠重現相應軟件故障的測試用例。
本文中提出一種基于用戶應用數據記錄與分析的錯誤還原方法,主要是利用用戶應用數據,實現錯誤再還原。設計一個具有代表性的待測試軟件,軟件窗口頁面如圖5(a)所示。該軟件擁有基本菜單功能,在此基礎上增加“對話框”菜單項。點擊“對話框”項后出現圖5(b)頁面。其中圖5(b)的功能:

圖5 待測軟件窗口
1)在“Number1”與“Number2”中分別輸入兩個數,點擊“divide”鍵后,“Number3”出現兩數相除的結果。此功能設計時應考慮除數不能為“0”,在計算結果之前應先判定除數是否為“0”。此處不做判斷,檢驗監測軟件監測結果;
2)“error”鍵:此處設計另一個錯誤,點擊“error”鍵后,軟件會對空指針賦值;
3)“Cancel”鍵:關閉此對話框;
4)“收縮/擴展”鍵:關閉/打開對話框下方展示部分。
監測軟件窗口頁面如圖6所示。其圖中各部分功能:
1)目標軟件選擇框:此框為下拉選擇框,監測軟件運行之后先訪問系統,將系統中所有的進程列至框內,供選擇;
2)“確定”鍵:選定目標進程后,點擊該鍵,監測軟件對指定進程進行監測;
3)“完成”鍵:監測工作完成,關閉軟件;
4)“取消”鍵:取消監測,關閉軟件。

圖6 監測軟件窗口
先運行待監測軟件,而后在監測軟件上對目標進程注入消息鉤子,開始記錄實驗數據。得到的操作記錄如圖7所示。

圖7 操作記錄
由實驗記錄的數據可知,目標軟件產生了大量操作,包括文件新建,文件打開,以及“對話”菜單生成對話框中相關功能。其中,操作過程中產生了兩個錯誤,相關錯誤代碼為“C0000094”,“C0000005”。通過查詢微軟公司發布的Microsoft Docs開發技術文檔可知,相關代碼含義分別為“線程試圖將整數值除以零的整數除數”,“該線程試圖讀取或寫入其沒有適當訪問權限的虛擬地址”。結果與實驗設計相吻合,生成相關的測試用例如表3所示。
目前有很多自動化回歸測試工具,例如QTP、WinRunner、QARun、VisualTest等。這類工具一般采用捕獲/回放的模式,記錄用戶操作的流程,保存下來作為備選測試用例,通過應用程序對流程腳本的自動執行來驗證被測系統的響應是否正確。以Quick Test Professional(簡稱QTP)為例,Micro Focus公司的QTP工具是一種自動測試工具,用于執行重復的自動化測試。通過自動錄制、檢測和回放用戶的應用操作,QTP工具能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試。
為了更加詳盡的對比QTP與監測軟件,設計QTP軟件對上述待測軟件進行監測,并且對待測軟件進行與第3.2節中相同操作,得到QTP記錄的實驗監測結果如圖8所示。

表3 軟件“divide”功能測試用例

圖8 QTP實驗監測結果
根據對比可以發現,QTP軟件能夠較為詳細的記錄目標軟件操作過程并且生成相應的測試用例。而本文中設計的監測軟件同樣能夠詳細的記錄并生成測試用例,除此之外,監測軟件會記錄下待測軟件不正常終止情況,并識別出相應的故障類型。顯然,運用本方法對待測軟件進行監測與故障識別更加有助于軟件測試工作的進行。本文設計的監測軟件與QTP的測試情況如表4所示。
相對已有的測試工具,本文中提出的監測軟件仍然存在一定不足。其中包括:軟件測試用例的生成尚未實現自動化與精簡,最簡化的測試用例仍需要依靠測試人員根本軟件報告多次測試生成;軟件錯誤定位還不夠精細,只能通過錯誤代碼與操作記錄綜合分析確定大概位置。

表4 監測軟件與QTP的測試情況
本文提出一種軟件運行監測與故障識別方法,通過監測程序監視用戶的操作和程序狀態,結合Windows錯誤報告和監測記錄對軟件動態故障進行識別和測試用例生成。通過實例證明,當程序出現故障時,合理借用Windows系統錯誤報告機制能夠有效地對軟件故障進行識別,并且結合用戶操作記錄,生成了能夠讓軟件故障重現的測試用例,為軟件發布之后的維護與升級提供了巨大幫助。
軟件運行過程中的數據報告除了可以用于故障識別之外,還可以用于具體錯誤的分析預定位與軟件可靠度分析。將軟件監測實現底層化,獲取更多的程序運行數據,軟件測試工作會更加深入。