測試帶有圖形用戶界面的未知程序的方法和裝置的制作方法

專利名稱：測試帶有圖形用戶界面的未知程序的方法和裝置的制作方法
技術領域：
本發(fā)明總體涉及用于自動地以系統(tǒng)的方式執(zhí)行和測試帶有圖形用戶界面(GUI)的未知可執(zhí)行程序以便使代碼覆蓋率最大化的方法和裝置，并且進一步涉及分析計算機病毒的方法和用于軟件測試的方法。
背景技術：
為了本專利申請的目的，將計算機病毒作如下定義病毒是一種在沒有直接的人類交互作用的情況下以可能變形的方式傳播的自我復制程序或例程。這一方面可參考共同受讓的美國專利號5,613,002，這里引用其全文作為參考。
自動軟件測試工具在所屬技術領域是已知的。例如，可參考Warfield的美國專利號5,754,760“Automatic Software testingtool”(自動軟件測試工具)和Parker等人的美國專利號5,600,789“Automated GUI Interface Testing”(自動化GUI界面測試)。也可以參考Halviatti等人的美國專利號5,475,843“System andMethods for Improved Program Testing”(用于改進的程序測試的系統(tǒng)和方法)。
某些類型的計算機病毒僅當特定的代碼段被執(zhí)行時才復制。這是因為，與普通病毒不同的是，它們把自己插入到宿主應用程序中的一個不是應用程序的入口的位置。為了復制這類病毒，必須嘗試測試程序的每個部分，即必須嘗試達到最大的代碼覆蓋率?？梢灾?，復制這些病毒是非常困難和耗費時間的，因為要求通過宿主程序的GUI對宿主程序的每一個特征功能(feature)進行系統(tǒng)的測試。在本發(fā)明之前，發(fā)明人不清楚有任何適合于復制這類計算機病毒的自動軟件評估或測試工具。

發(fā)明內容
按照本發(fā)明實施方案的方法和裝置克服了上述的和其它的問題。
本發(fā)明的第一個方面是提供一種實現(xiàn)計算機病毒的自動復制的機制。
本發(fā)明的第二個方面是提供以模擬不熟悉應用程序的特征功能的沒有經(jīng)驗的用戶的動作的方式實現(xiàn)對帶有用戶界面的計算機軟件應用程序的自動測試的方法和裝置。
公開一種用于自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程的方法，一種用于實現(xiàn)該方法的系統(tǒng)和一種存儲在計算機可讀介質上的體現(xiàn)該方法的計算機程序。該方法包括計算機執(zhí)行的以下步驟開始目標應用程序進程；檢測由目標應用程序進程打開的第一窗口的出現(xiàn)；通過確定第一窗口的內容包括用戶控件(controls)列表，處理第一窗口；測試用戶控件，一直到所有的用戶控件都已經(jīng)被測試，有可能導致終止(termination)的用戶控件被識別并在較小可能導致終止的用戶控件之后被測試；關閉第一窗口。測試的步驟包括估計用戶控件的最佳執(zhí)行順序和要被輸入到用戶輸入欄的文字的步驟。如果測試某特定用戶控件導致第一窗口在第一窗口的所有用戶控件已經(jīng)被測試之前就關閉，該方法進一步包括以下步驟重新打開第一窗口；除非要求該特定用戶控件在該窗口的所有用戶控件都被測試后關閉第一窗口，否則測試該窗口的除該特定用戶控件以外的用戶控件。
如果測試某特定用戶控件導致第二窗口打開，該方法包括以下步驟確定包括用戶控件列表的第二窗口的內容；測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試；關閉第二窗口；繼續(xù)對第一窗口的處理。
測試的步驟包括估計用戶控件的最佳執(zhí)行順序和要被輸入到用戶輸入欄的文字的步驟，最好至少部分地根據(jù)從打開的窗口獲得的信息進行估計。該順序確定適用于所有的用戶控件，諸如按鈕控件、編輯前選擇欄(selection fields before edit)控件、按鈕控件前編輯控件(edit controls before button controls)、等等。
在各個用戶控件被測試之后，本方法包括的進一步的步驟是枚舉系統(tǒng)窗口；確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因新的窗口被打開而產(chǎn)生的變化；如果已經(jīng)有變化，則在恢復處理第一窗口之前處理該新窗口。該方法的這個方面進一步通過比較目標應用程序進程的程序標識與每個新打開的窗口的程序標識而確定新打開的一個或多個窗口是否是與目標應用程序相關聯(lián)的。如果新窗口不是與目標應用程序相關聯(lián)的，該方法就通過處理該新窗口或關閉該新窗口而繼續(xù)；然后繼續(xù)處理第一窗口。如果檢測到多個新窗口已經(jīng)被打開，該方法確定該多個新窗口之間是否存在父子關系。如果發(fā)現(xiàn)存在父子關系，該方法就在處理父窗口之前處理子窗口。如果沒有發(fā)現(xiàn)該多個新窗口之間存在父子關系，該方法可以以任意順序處理該多個新窗口；然后繼續(xù)處理第一窗口。
處理的步驟包括一個維持一個與目標應用程序相關聯(lián)的窗口的列表的步驟，該列表含有每個窗口的編號(handle)、名稱、類、窗口中含有的用戶控件列表、窗口的狀態(tài)、和已經(jīng)導致該窗口關閉的任何用戶控件的標識。兩個窗口僅當如果它們至少有相同的類、名稱和用戶控件時才被視為是相同的，并且如果某新窗口至少有與窗口列表中現(xiàn)有的某窗口相同的類、名稱和用戶控件時，就不把新窗口添加到窗口列表中，而是把列表中的對應窗口的編號及其用戶控件作相應的更新。
在該方法的優(yōu)選實施例中，對話(dialog)用戶控件的處理的順序根據(jù)的是它們的類型，其中，組合框對話用戶控件首先被處理，接著是編輯欄，接著是按鈕用戶控件。在按鈕用戶控件中，最可能導致終止的那些按鈕用戶控件被最后處理。
組合框包括一個與一個靜態(tài)控件(static control)或者編輯控件(edit control)組合的列表框?？丶牧斜砜虿糠挚梢栽谒袝r間內都被顯示，或者可以僅當用戶選擇控件旁邊的下拉(drop-down)箭頭時才下拉(drop down)。這個控件和其它控件的說明見于微軟出版社出版的微軟開發(fā)者網(wǎng)絡知識庫(Microsoft Developer Networkknowledge base)中，特別是在出版物“Visnal C++程序員指南”“Visual C++programmer guide”中。
用戶控件也可以包括菜單項和子菜單項，在執(zhí)行的步驟期間，通過發(fā)送一個命令消息來模擬在某特定菜單或子菜單項上的點擊，在Windows環(huán)境中，這個命令消息諸如是一個發(fā)往目標應用程序進程的WM_COMMAND消息，傳送命令標識作為參數(shù)。處理的步驟包括一個進一步的創(chuàng)建一個所有子菜單項列表的步驟，以及一個通過考慮每個菜單項的名稱及其位置而確定測試菜單項的順序的步驟，那些可能導致終止的菜單項在最后被執(zhí)行。
附圖簡介隨后的發(fā)明詳述結合附圖更清楚地說明本發(fā)明的上述以及其它特點。


圖1是適合于實現(xiàn)和實踐本發(fā)明的數(shù)據(jù)處理系統(tǒng)的框圖；圖2、3和4是按照這些示教的方法的邏輯流程圖；圖5表示一個具有菜單和編輯區(qū)的典型應用程序窗口；和圖6表示一個典型的對話窗口。
發(fā)明詳述作為介紹，參看表示典型的應用程序窗口的圖5和6。常規(guī)的帶有GUI的應用程序可能包括一個或多個這樣的窗口。典型的窗口含有標題501、601，并且一般包含界面對象的多個主要類型(interfaceobjects)例如，帶有子菜單505和控件或者僅帶有控件的菜單504、505?？丶ㄈ魏畏N類的按鈕，諸如按鍵式按鈕(push button)606、607，單選按鈕(radio button)605，復選框(check box)等等，還包括允許用戶輸入的欄506和604，選擇框和其它界面對象。這些控件的每個本身就是窗口，可被視為包含窗口的“子”窗口。這個父-子關系使用戶能獲得由每個窗口顯示的控件的一個列表。在這些示教的優(yōu)選實施例中，只有標準類型的控件被處理，因為這些控件是最常見的。然而，這些示教并不僅僅限于只處理標準類型的控件，而是可以包括各種各樣的控件類型。
應當注意到，盡管在系統(tǒng)上的頂層窗口之間有父-子關系，例如，某個作為對主窗口的操作結果而顯示的對話窗口被視為該主窗口的一個字窗口，窗口中包含的對象經(jīng)常是用特殊的標志來區(qū)分的。例如，在微軟視窗系統(tǒng)上，包含在某窗口內的對象有一個顯示的WS_CHILDWINDOW標志，而頂層窗口則沒有。如果有關的特定窗口不采用這種標志，則可能需要根據(jù)可獲得的系統(tǒng)特定的信息對關系進行估計或猜測。例如，在一個假設的系統(tǒng)中，編號數(shù)量(handle numbers)可能存在差別。
通過“點擊”各種控件或菜單項，以及在諸如編輯框等用戶可控制的欄中設置信息，按照這些示教的方法，自動地模擬各個用戶的動作。這些示教的一個重要方面是不要求對GUI各部件有預先的知識。
盡管可能由若干種方法向另一個程序發(fā)送信息，這些示教的目前的優(yōu)選實施例利用窗口消息接發(fā)(messaging)和標準應用程序接口(APIs)進行通信。不過，本發(fā)明的示教并不限于僅僅使用一種特定類型的消息接發(fā)和/或APIs?？傊?，對APIs和消息的說明是平臺特定的，能在對應特定平臺的文件中找到。僅舉一個例子，對于Window環(huán)境來說，可以在微軟開發(fā)者網(wǎng)絡知識庫提供的Platform SDKWindows UserInterface文件中找到Windows APIs的說明。
圖1中所示的框圖表示系統(tǒng)的基本結構。在這個示意圖中，假設目標應用程序進程104顯示窗口122。目標應用程序進程104被懷疑可能染上了計算機病毒，諸如上文中討論的類型的計算機病毒。為了驗證計算機病毒的存在，以及/或者獲得多個該計算機病毒的樣本或實例，有必要盡可能徹底地測試目標應用程序進程104。圖1中所表示的系統(tǒng)用于以自動的方式執(zhí)行這個任務，而無需具有目標應用程序進程104的或各種窗口的細節(jié)的預先知識，包括其GUI可能采用的用戶控件和對話框?？刂破?00用進程API 103和消息接發(fā)API 121測試目標應用程序進程104。
在本優(yōu)選實施例中，控制器100的主要部件包括一個程序分析器101，它控制處理的各個方面，并維持窗口的列表，包括當前在系統(tǒng)窗口列表109中和在應用程序窗口列表116中顯示的那些窗口?？刂破?10因此進一步包括一個窗口枚舉器106、一個窗口探測器112和一個窗口處理器119。窗口枚舉器106用進程API 103枚舉(107)所有當前打開的窗口，進程API 103返回唯一地標識窗口系統(tǒng)上打開的每一個窗口的編號。窗口枚舉器106用系統(tǒng)窗口列表109來確定在列表創(chuàng)建以后已經(jīng)被打開的窗口。新打開的窗口的編號然后被傳送(110)到程序分析器101，程序分析器確定那些屬于目標應用程序進程104的窗口。目標應用程序進程104的新打開的窗口的編號被逐個地傳送(111)到窗口探測器112，窗口探測器然后用每個窗口編號來確定每個窗口是否已經(jīng)被看到，或者還是新的。這可以通過檢查在路徑113上接收的來自已經(jīng)存儲在應用程序窗口列表116中的關于每個窗口的信息而實現(xiàn)。在前一種情況下，“新的”窗口已經(jīng)被看到，窗口探測器用窗口的新編號和其控件的新編號來更新(114)應用程序窗口列表116中的新打開的窗口的條目。在后一種情況下，新打開的窗口以前沒被看見過，窗口探測器112在路徑115上把該新窗口的條目加到應用程序窗口列表116中并確定其控件和菜單項。每個新打開的窗口的編號然后通過路徑118被傳送到窗口處理器119，后者用應用程序窗口列表116中含有的信息來測試窗口122的每個控件。
應當注意的是，事實上，盡管能用新打開的窗口的窗口編號來獲得窗口信息(類、名、控件列表)，如果窗口已經(jīng)在被關閉后再打開，則存儲在應用程序窗口列表116中的編號信息是過時的，但是其余信息仍然是可用的。
人們在試圖自動化一個未知程序時遇到的一個重要問題是通常缺少關于控件必須被按下或測試的預期順序的信息，以及預期要被傳送到用戶可控制的窗口欄的信息的類型。
測試這樣的程序的最直截了當?shù)姆绞绞呛唵蔚仉S機測試菜單項和控件。然而，這個技術有許多缺點。例如，它可能導致目標應用程序進程104的立即終止，因為它最可能導致產(chǎn)生太多的錯誤條件，甚至導致開始一個無限循環(huán)。
這些技術所采用的一個更有用的方法是試圖根據(jù)從每個個別窗口獲得的信息估計各個窗口的內容、預期的輸入以及最佳執(zhí)行順序。就是說，對各個窗口的內容、預期的輸入以及用戶控件的最佳執(zhí)行順序的估計，根據(jù)的是從窗口派生出的關聯(lián)內容，可能也根據(jù)某種試探法，諸如由某類型的用戶可加載文本框所預期的典型輸入(例如文件名，或者某種類型的設備，諸如驅動程序的標識與打印機的標識等。)控制處理的最佳順序是由最佳順序確定部件117在視窗探測器112獲得新窗口的控件列表時確定的。對最佳順序確定部件的輸入來自一個名為控件的序列列表123的模塊。
最佳順序確定部件117的任務由于大多數(shù)GUI應用程序都使用許多標準窗口而被簡化。最常見的界面，類型例如多文檔界面(MDI-Multiple Document Interface)或單文檔界面(SDI)，含有在第一子菜單中的文件操作(新建、打開、關閉、...、退出)菜單，以及大的用戶可控欄(見圖5，特別是部件502-505以及506)。此外，許多應用程序所顯示的許多對話都是標準的(打開、另存、尋找、替換、等等)。通過利用這些對話的常見外觀，程序或控制器100就能對最常見的操作順序以及預期在用戶可控欄中的信息作出準確的估計。
在處理未知窗口時，最好使用最常用的處理順序。例如，大多數(shù)對話都要求用戶首先從列表中選擇信息，然后在編輯欄敲入數(shù)據(jù)，用其它控件設置選項，最后點擊按鍵式按鈕。對有些按鈕的點擊有可能導致對話的終止。本文將這些類型的按鈕稱作“終止”按鈕，“終止”按鈕的執(zhí)行最好放在對給定窗口的處理的最后。例如，在圖6中，指示符606表示終止按鈕“OK”(同意)和“取消”。
從圖6中顯而易見，一個窗口可含有多個“終止”按鈕。此外，其它欄還可以導致窗口的終止。因此，窗口可能會在其所有控件都被處理之前消失。然而，為了最大化代碼覆蓋率(code coverage)，在窗口關閉之前應當測試窗口中存在的所有的控件。
按照本發(fā)明當前的優(yōu)選實施例，如果新窗口在其所有的控件都被探測和測試之前就消失，則重復最初導致窗口顯示的操作，直到窗口中所有的控件都被處理，但是不要重復導致窗口關閉的步驟，除非需要它來終止窗口并且它是唯一的終止控件。
許多操作通常將導致另一個窗口或幾個窗口被顯示。在這種情況下，在繼續(xù)處理最初的窗口之前，要對每個新打開的窗口循環(huán)地應用所述的方法。一旦新窗口被處理，控制就被返回到先前被處理的窗口，在下一個界面對象處恢復其界面對象的處理。
反映按照本發(fā)明的示教的方法被表示在圖2、3和4中的邏輯流程圖中。
以圖2作為開始，也參看圖1，在步驟201，先從系統(tǒng)窗口列表109獲得系統(tǒng)上所有打開的窗口的列表，再在步驟202啟動應用程序。在步驟203再次枚舉各窗口，以便在步驟204確定是否有任何窗口被在步驟202啟動的應用程序顯示過。如果該應用程序沒有顯示過任何窗口，則假設該應用程序沒有GUI，因此不能被本方法測試。在這種情況下，本方法終止。如果有一個或多個窗口被目標應用程序進程104顯示，就處理每個新打開的窗口，如圖3中所示的那樣，直到所有新窗口都被處理(步驟205、206)。
參看圖3，控件列表和菜單項在步驟301被創(chuàng)建并按照優(yōu)選的測試順序被排序?？梢詫⑴藕眯虻牧斜泶鎯υ诳丶男蛄辛斜?23中，供窗口處理器119使用。在步驟302，判斷以前是否看到過當前的窗口。如果看到過，則在步驟303用新的編號更新控件列表，否則，在步驟304確定關于新窗口的信息并將其加到應用程序窗口列表116中。在步驟305和307，按確定的順序處理當前打開的窗口中的每個控件，直到所有控件都被處理，此時，在步驟306判斷窗口(在所有控件都已經(jīng)被處理后)是否仍然被顯示。如果窗口仍然被顯示，則在步驟308例如利用WM_CLOSE(...)消息將其強行關閉。各個窗口處理例程然后退出，然后在步驟205繼續(xù)對下一個新窗口的處理。
現(xiàn)在再次參看圖3的處理下一個控件的步驟307，并參看圖4中獲得更多細節(jié)，在每個控件被處理后，窗口在步驟401再次被枚舉。任何屬于目標應用程序進程104的新窗口都在步驟403、404和405(圖2的步驟204)被循環(huán)地處理。一旦完成，就在步驟405檢測對新顯示的窗口的處理是否過早地終止(窗口關閉或者消失)。在這種情況下，個別窗口處理通過適當?shù)姆祷卮a退出。該代碼在步驟404中被檢測。
應當注意的是，一旦確定某控件導致窗口過早地關閉，則最好不要再次調用該同一個控件。這避免啟動一個無限循環(huán)的可能，因為在隨后的窗口處理調用中，要測試不同的控件。
目標應用程序進程104可以因為一個命令而終止。在這種情況下，目標應用程序進程104被重新啟動。為了最大化覆蓋率，避免不必要的重復和可能的無限循環(huán)，在圖1的應用程序窗口列表116中保持一個界面覆蓋率的尺度(metric)。就是說，保持一個導致目標應用程序進程104終止的步驟的記錄。如果目標應用程序進程104被重新啟動，則測試目標應用程序進程104的方法在下一個步驟繼續(xù)。導致程序終止的步驟不被重復(除非以后需要它來終止目標應用程序進程)。當足夠的代碼覆蓋率被檢測過后，該方法終止。如果為計算機病毒復制的目的-諸如為了獲得特定計算機病毒的一些實例-而執(zhí)行本發(fā)明的方法，則該方法在這個目的實現(xiàn)時終止。
關于代碼覆蓋率的測量，可以通過任意適當?shù)姆椒ɑ蛲獠坑绊懘_定一個表示這個代碼覆蓋率的量的適當?shù)淖钚≈担@不必是本發(fā)明的示教的一部分。
關于屬于目標應用程序進程104的窗口的識別，圖1的程序分析器101的其中一個任務是識別新打開的窗口122哪些屬于目標應用程序進程104。這是在該方法的早期通過進程API 103確定目標應用程序進程104的進程id以及通過比較所識別的目標應用程序進程id與每個新打開的窗口的id而完成的。
系統(tǒng)顯示的每個窗口122被賦予一個唯一的編號。所有其它關于窗口的信息，包括其名稱、類、和創(chuàng)建它的進程的id，都可以通過標準APIs用窗口編號獲得。例如，EnumWindows(...)API遍歷系統(tǒng)中的所有頂層窗口并可以將每個窗口的窗口編號傳送給用戶提供的回叫(callback)程序。只要目標應用程序進程104的進程id是已知的，就能很方便地確定屬于目標應用程序進程104的窗口。根據(jù)目標應用程序進程104是如何被調用的，進程id可能是已知的。例如，如果目標應用程序進程104是通過CreateProcess(...)API調用來啟動，則進程id是已知的。
另一個用于在不知道目標應用程序進程104的進程id時確定目標應用程序窗口122的技術是在目標應用程序進程104被啟動之前和之后調用EnumWindows(...)。這樣在該方法執(zhí)行的自始至終保持系統(tǒng)上所有窗口的列表(系統(tǒng)窗口列表109)。
關于新窗口的處理，在測試一個界面對象之后出現(xiàn)的任一新窗口都被通過在每個操作之前和之后枚舉頂層窗口而識別。這是窗口枚舉器106的任務。
在有些情況下，新窗口可能屬于另一個應用程序。例如，在有些應用程序中激活一個幫助(Help)菜單項將導致調用窗口幫助程序。發(fā)生這種情況時，可以采取兩種行動方式。在優(yōu)選實施例中，新的程序被循環(huán)地測試。然而這可能并不切合實際，因為這對效率有相當大的影響。在另一個實施例中，任何打開的新窗口如果不屬于當前正在測試的目標應用程序進程104，就被立即關閉。
在多數(shù)情況下，一個操作將導致一個新窗口的出現(xiàn)。然而，在有些情況下，可能出現(xiàn)兩個或更多的窗口。由于這些示教的目標是在最大可能的程度上模擬普通用戶的行動，最好以用戶與新窗口交互的相同的方式處理新窗口。為了確定用戶如何選擇首先操作的窗口，了解多個窗口被典型的應用程序顯示時的條件是重要的。
被應用程序顯示的窗口例如可能是另一個菜單窗口(例如MDI界面中的一個新視圖(view)或相同窗口的一個新視圖)、一個在繼續(xù)程序之前要求用戶響應的模式對話(modal dialog)、或者一個停留在屏幕上并且任何時候都能被使用的無模式對話(modeless dialog)，但是允許其它用戶活動。由于無模式對話框任何時候都能被使用，它們的執(zhí)行的選擇順序并不重要。
當應用程序一次顯示多于一個窗口時，這經(jīng)常是以下操作的結果應用程序試圖顯示一個窗口(例如模式對話框或另一個視圖)；或者窗口處理模塊119檢測到錯誤或者要求額外的信息并因此顯示另一個用來獲得這個信息的窗口(如果第一窗口是個視圖，則該另一個窗口一般是消息框(message box)或模式對話框)。
在這兩種情況下，新顯示的窗口大多都可能互相具有父子關系，要被首先處理的窗口是沒有頂層子窗口的窗口。
例如，在以下情況中程序->程序的子窗口A->窗口A的子窗口B因此，窗口B先被處理，接著是窗口A。
如果新顯示的窗口互相沒有父子關系，則假設它們的處理順序無關緊要，可以隨機地或者通過試探法選擇下一個要被處理的窗口。
關于各個窗口的處理，該方法保持與正在被測試的目標應用程序進程104有關的窗口的列表(列表116)。被保持的關于每個應用程序窗口的信息包括其編號、名稱(在窗口頂部顯示的名稱)、類(被系統(tǒng)使用的內部標識符)、包含在窗口中的界面對象的列表、窗口的狀態(tài)(打開的或是關閉的)、覆蓋率信息和導致窗口關閉的界面對象。
窗口編號僅僅在窗口打開(在系統(tǒng)上被顯示)期間是恒定的。當窗口被關閉后再被打開時，其編號改變。這在窗口在處理結束之前關閉然后為完成處理而被重新打開的情況中產(chǎn)生額外的復雜性。在這些情況中，最好識別該窗口為部分處理過的窗口。類一名組合并非總是唯一地識別窗口，因為窗口可能有相同類和名，而有不同外觀。因為在本例中窗口的外觀和感覺很重要，所以僅當兩個窗口有相同的類、名稱和控件，則認為它們是相同的。如果新打開的窗口有與應用程序窗口列表116上現(xiàn)有的某窗口相同的名稱、類和控件，就不把它加到列表116中。相反，通過路徑114由窗口探測器112更新列表116上的對應窗口的編號及其每個控件。
盡管有時需要不止一次地使用非終止(non-terminal)控件，對菜單項來說則不是這樣。例如，在對話被取消(Cancel)按鈕關閉之前以及被OK按鈕關閉之前，有可能需要在輸入欄中設置一個值并選取一個或多個框。然而，沒有理由在每次打開窗口時重復測試相同的菜單項。因此，不管某窗口被打開多少次，每個菜單項最好只用一次。
既避免終止(terminal)控件又避免以前用過的菜單項，在解決使用一個界面對象導致同一個窗口有不同外觀-例如出現(xiàn)另外的控件或菜單項-的情況中是有好處的。這種情況表現(xiàn)為用具有相同的類和名稱但是不同的控件的新窗口替換老窗口。因為該新窗口具有不同的控件，所以就本發(fā)明示教的目的而言，將其視為一個新窗口。然而，如果對這種情況的處理不當，會導致產(chǎn)生無限循環(huán)(1)窗口1對象1對象2->窗口1被替換為窗口2(相同名稱和類)對象3(2)窗口2對象1對象2->窗口2被替換為窗口1對象3(3)窗口1對象1對象2->窗口1被替換為窗口2對象3等等。
避免已經(jīng)被探測過并且被確定是終止的窗口對象能解決這種情形，因為(3)中的新窗口將被認為是部分處理過的窗口(1)，對象2被認為是終止對象。對象2因此將不被重復。如果對象1和對象2二者都是菜單項，則它們的任意一個都不在(3)中被重復使用。因此，在這種情況下，步驟(3)類似于如果對象1、對象2和對象3是控件，則對象2被作為終止對象而跳過(3)窗口1對象1對象3如果對象是菜單項，則對象1和對象2二者都被跳過(3)窗口1對象3關于獲得窗口的界面對象的列表，要注意的是，為了模擬GUI的用戶，該方法需要獲得某些關于每個窗口的外觀(look)的信息。該信息包括-但不限于-窗口名稱和類、窗口菜單的出現(xiàn)和內容、以及控件的類型和外觀。關于菜單項的信息可以用標準APIs獲得。例如，在微軟視窗TM系統(tǒng)中，所使用的APIs是GetMenu(...)和GetSubMenu(...)。
關于控件的信息可以用窗口的父子關系獲得。這是因為在窗口系統(tǒng)中，所有的控件也是窗口，某個窗口中含有的所有控件都是含有這些控件的窗口的子窗口。因此，特定窗口的所有控件的列表可以通過利用標準窗口APIs遍歷該特定窗口的子窗口的列表而獲得。
至少有兩個與窗口控件有關的問題。第一個問題是對諸如編輯欄等輸入欄的值的選擇。第二個問題是各個控件應當被使用的順序。
在一個實施例中，標準對話是通過它們的名稱被識別的。然而，如果應用文字是英語以外的語言，這個方法并不可取。因此，在優(yōu)選實施例中，要確定目標應用程序進程104的語言，詞庫124向最佳順序確定單元117提供一個輸入。詞庫124被用來確定標準對話的名稱和識別標準按鈕上的文字。關于對話的類型的信息，可被用在對要被傳送到輸入欄的信息的類型的確定中以及對執(zhí)行順序的確定中。
有幾個標準類型的窗口控件，它們所有最好被按照本示教的方法處理?？丶念愋褪怯善浯翱陬惔_定的。例如，實現(xiàn)編輯(Edit)控件的窗口將有一個類“Edit”(編輯)或“RichEdit”(復文本編輯)。組合框窗口將有一個類“ComboBox”。復選框、單選按鈕、按鍵式按鈕將有一個類“Button”(按鈕)。當幾個類型的控件被同一個類代表時--如在按鈕控件中的那樣，則可以通過標準APIs獲得更詳細的信息。
對Edit控件的值的選擇是要重點考慮的，因為對Edit控件值的不正確選擇通常將檢測目標應用程序進程104的一般是最簡單的錯誤路徑。盡管一般不可能總是猜到預期的值，本方法的本實施例檢查對話的類型及其其它控件，諸如Combo框。也有可能通過分析在與輸入欄相鄰的靜態(tài)控件中顯示的文字來“猜測”預期的值。例如，Open(打開)對話的值應當是一個現(xiàn)有文件的名稱。這個文件的最可能的擴展名是該欄中當前規(guī)定的擴展名，或者是在同一個對話上顯示的Combo框欄中含有的擴展名。
本方法的本實施例處理“可設置”控件的最可能的設置，而優(yōu)選實施例測試有效的和無效的兩種設置。
對話控件的處理的順序以它們的類型為根據(jù)。例如，Combo框一般首先被處理，接著是Edit欄，各按鈕被最后處理，因為它們可能導致對話的終止。按鈕中那些最可能導致對話終止的按鈕(打開、另存、OK、取消、等等)被最后處理?？梢詫⑦@個序列信息存儲在控件模塊的序列的列表123中。
因為某對話可能在其所有控件被處理之前就終止，對話可能需要被多次調用。為了避免開始一個無限循環(huán)，所有被確定是終止控件的控件都不再被處理，直到對話被完全處理。
關于菜單項的處理，可獲得的關于每個菜單或子菜單項的信息包括其名稱(打開、關閉、等等)和其命令標識符。命令標識符是一個號碼，當用戶點擊菜單項時，該號碼能作為WM_COMMAI消息中的參數(shù)被傳送。因此，為了讓本方法模擬在特定菜單項上的鼠標“點擊”，該方法向目標應用程序進程104發(fā)送一個WM_COMMAI消息，將命令id作為參數(shù)傳送。一旦所有子菜單項的列表被創(chuàng)建后，菜單項的測試順序就被確定。在優(yōu)選實施例中，測試菜單項的有意義的順序的有限列表。在確定順序時，最好對每個菜單項的名稱及其位置都加以考慮。與控件一樣，導致程序終止的菜單項最后被執(zhí)行。在一個實施例中，首先測試第一個菜單項(最可能是New(新建))，接著是所有的窗口控件，接著是其余的菜單項。
應當注意的是，以上討論的各種功能都能用在圖1的系統(tǒng)控制器上執(zhí)行的軟件來實現(xiàn)。因此，本發(fā)明的教導也涉及一種體現(xiàn)在計算機可讀介質上的計算機程序?？梢赃\行該程序來通過引導計算機開始目標應用程序進程而自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程；檢測被目標應用程序進程的GUI打開的窗口的出現(xiàn)；通過確定窗口的內容，包括在窗口中發(fā)現(xiàn)的用戶控件的列表，處理打開的窗口；按照計算機程序估計的順序測試用戶控件，直到所有用戶控件都被測試過；然后關閉窗口。如果測試特定用戶控件導致窗口在所有用戶控件都被測試之前就關閉，則程序進一步引導計算機重新打開窗口，然后測試除了該特定用戶控件以外的用戶控件，除非在所有用戶控件都被測試過后需要該特定用戶控件來關閉窗口。如果測試某特定用戶控件導致第二窗口打開，則程序進一步引導計算機確定第二窗口的內容，包括用戶控件列表；測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試；關閉第二窗口；然后繼續(xù)對第一窗口的處理。在各個用戶控件被測試過后，程序引導計算機枚舉系統(tǒng)窗口，以確定是否所枚舉的系統(tǒng)窗口中由于多個新窗口被打開而變化，以確定是否在多個新窗口之間存在父子關系，如果存在父子關系，就在處理父窗口之前處理子窗口，然后繼續(xù)對第一窗口的處理。在測試用戶控件一直到所有用戶控件都被測試時，最好將可能導致終止的用戶控件被識別出來并在不太可能導致終止的用戶控件之后測試。
盡管本發(fā)明的教導可以被應用于這樣的系統(tǒng)-其中需要引出在被懷疑隱藏有病毒的程序中的病毒活動，和/或獲得被懷疑的病毒的樣本，但是本發(fā)明的教導并不僅僅限于這一個重要應用。
因此，盡管是就本發(fā)明的優(yōu)選實施例對本發(fā)明作出特定表示和說明的，本領域的熟練人員應當明白，在不偏離本發(fā)明的精神和范圍的情況下可以對本發(fā)明的形式和細節(jié)作出改變。
權利要求
1.一種用于自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程的方法，包含計算機執(zhí)行的以下步驟啟動目標應用程序進程；檢測由目標應用程序進程打開的第一窗口的出現(xiàn)；通過確定第一窗口的包括用戶控件列表的內容，處理第一窗口；測試用戶控件，一直到所有的用戶控件都已經(jīng)被測試，有可能導致終止的用戶控件被識別出來并在較小可能導致終止的用戶控件之后被測試；和關閉第一窗口。
2.如權利要求1中所述的方法，其中，如果測試某特定用戶控件導致第一窗口在第一窗口的所有用戶控件已經(jīng)被測試之前就關閉，該方法進一步包括以下步驟重新打開第一窗口；和除非要求該特定用戶控件在該第一窗口的所有用戶控件都被測試后關閉第一窗口，否則測試除該特定用戶控件以外的用戶控件。
3.如權利要求1中所述的方法，其中，如果測試某特定用戶控件導致第二窗口打開，該方法包括以下步驟確定第二窗口的內容，包括用戶控件列表；測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試；關閉第二窗口；和繼續(xù)對第一窗口的處理。
4.如權利要求1中所述的方法，其中，測試的步驟包括估計用戶控件的最佳執(zhí)行順序和要被輸入到用戶輸入欄的正文的步驟。
5.如權利要求1中所述的方法，其中，測試的步驟包括估計按鈕用戶控件的最佳執(zhí)行順序和要被輸入到用戶輸入欄的正文的步驟。
6.如權利要求1中所述的方法，其中，在各個用戶控件被測試之后，該方法包含的進一步的步驟是枚舉系統(tǒng)窗口；和確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因新的窗口被打開而產(chǎn)生的變化；和如果已經(jīng)有變化，則在恢復處理第一窗口之前處理該新窗口。
7.如權利要求1中所述的方法，其中，在各個用戶控件被測試之后，該方法包含的進一步的步驟是枚舉系統(tǒng)窗口；和確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因一個或多個新的窗口被打開而產(chǎn)生的變化；和通過比較目標應用程序進程的進程id與每個新打開的窗口的進程id而識別新打開的一個或多個窗口是否是與目標應用程序相關聯(lián)。
8.如權利要求1中所述的方法，其中，在各個用戶控件被測試之后，該方法包含的進一步的步驟是枚舉系統(tǒng)窗口；和確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因至少一個新的窗口被打開而產(chǎn)生的變化；通過比較目標應用程序進程的進程id與每個新打開的窗口的進程id而識別新打開的窗口是否是與目標應用程序相關聯(lián)；如果新窗口不是與目標應用程序相關聯(lián)的，處理該新窗口或關閉該新窗口；和繼續(xù)處理第一窗口。
9.如權利要求1中所述的方法，其中，在各個用戶控件被測試之后，該方法包含的進一步的步驟是枚舉系統(tǒng)窗口；和確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因多個新的窗口被打開而產(chǎn)生的變化；確定該多個新窗口之間是否存在父子關系；如果存在父子關系，在處理父窗口之前處理子窗口，否則以任意順序處理該多個新窗口；和繼續(xù)處理第一窗口。
10.如權利要求1中所述的方法，其中，處理的步驟包括一個維持與目標應用程序相關聯(lián)的窗口的列表的步驟，該列表含有每個窗口的編號、名稱、類、窗口中含有的用戶控件列表、窗口的狀態(tài)、和已經(jīng)導致該窗口關閉的任何用戶控件的標識。
11.如權利要求10中所述的方法，其中，兩個窗口僅當如果它們至少有相同的類、名稱和用戶控件時才被視為是相同的，并且其中如果某新窗口至少有與窗口列表中出現(xiàn)的某窗口相同的類、名稱和用戶控件時，就不把新窗口添加到窗口列表中，而是把列表中的對應窗口的編號及其用戶控件作相應的更新。
12.如權利要求1中所述的方法，其中，對話用戶控件的處理順序以它們的類型為根據(jù)。
13.如權利要求12中所述的方法，其中，Combo框對話用戶控件首先被處理，接著是編輯欄，接著是按鈕用戶控件，其中在按鈕用戶控件中，最可能導致終止的那些按鈕用戶控件被最后處理。
14.如權利要求1中所述的方法，其中，用戶控件包括菜單項，其中在執(zhí)行的步驟期間，通過向目標應用程序進程發(fā)送一個命令消息來模擬在某特定菜單項上的點擊，將命令id作為參數(shù)傳送。
15.如權利要求1中所述的方法，其中，用戶控件包括菜單項和子菜單項，其中處理的步驟包括創(chuàng)建一個所有子菜單項列表的步驟，以及一個通過考慮每個菜單項的名稱及其位置而確定菜單項的測試順序的步驟，那些可能導致終止的菜單項在最后被執(zhí)行。
16.一種用于自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程的計算機系統(tǒng)，包含用于利用應用程序界面(APIs)開始和測試目標應用程序進程的控制器，所述控制器檢測由GUI目標應用程序進程打開的第一窗口的出現(xiàn)；作為響應，通過確定第一窗口的包括用戶控件列表的內容，處理第一窗口；所述控制器進一步測試用戶控件，一直到所有的用戶控件都已經(jīng)被測試，然后關閉第一窗口，有可能導致終止的用戶控件被識別出來并在較小可能導致終止的用戶控件之后被測試。
17.如權利要求16中所述的系統(tǒng)，其中，如果測試某特定用戶控件導致第一窗口在第一窗口的所有用戶控件已經(jīng)被測試之前就關閉，所述控制器作出以下響應重新打開第一窗口；除非要求該特定用戶控件在該窗口的所有用戶控件都被測試后關閉第一窗口，否則測試除該特定用戶控件以外的用戶控件。
18.如權利要求16中所述的系統(tǒng)，其中，如果測試某特定用戶控件導致第二窗口打開，所述控制器作出以下響應確定第二窗口的內容，包括用戶控件列表；測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試；關閉第二窗口；繼續(xù)對第一窗口的處理。
19.如權利要求16中所述的系統(tǒng)，其中，控制器估計包括按鈕用戶控件在內的用戶控件的最佳執(zhí)行順序，和要被輸入到用戶輸入欄的正文。
20.如權利要求16中所述的系統(tǒng)，進一步包含一個打開系統(tǒng)窗口的列表和一個窗口枚舉單元，窗口枚舉單元響應各個用戶控件被測試用來枚舉系統(tǒng)窗口以及確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因新的窗口被打開而產(chǎn)生的變化，其中所述控制器響應所確定的變化對于在恢復處理第一窗口之前有選擇地處理新窗口。
21.如權利要求20中所述的系統(tǒng)，其中，所述窗口枚舉單元通過比較目標應用程序進程的進程id與每個新打開的窗口的進程id而識別新打開的窗口是否是與目標應用程序相關聯(lián)。
22.如權利要求21中所述的系統(tǒng)，其中，如果新打開的窗口不是與目標應用程序相關聯(lián)的，則所述控制器進一步進行操作，以處理新打開窗口或關閉新打開窗口，然后繼續(xù)處理第一窗口。
23.如權利要求20中所述的系統(tǒng)，其中，如果所述窗口枚舉單元確定在所枚舉的系統(tǒng)窗口中已經(jīng)有因多個新的窗口被打開而產(chǎn)生的變化，所述控制器作出的響應是確定該多個新窗口之間是否存在父子關系；如果確定存在父子關系，則在處理父窗口之前處理子窗口，否則所述控制器以任意順序處理該多個新窗口；然后繼續(xù)處理第一窗口。
24.如權利要求16中所述的系統(tǒng)，進一步包含一個與目標應用程序相關聯(lián)的窗口的列表，該列表含有對應于每個窗口的窗口編號、名稱、類、窗口中含有的用戶控件列表、窗口的狀態(tài)、和已經(jīng)導致該窗口關閉的任何用戶控件的標識。
25.如權利要求24中所述的系統(tǒng)，其中，兩個窗口僅當如果它們至少有相同的類、名稱和用戶控件時才被視為是相同的，并且其中如果某新窗口至少有與窗口列表中現(xiàn)有的某窗口相同的類、名稱和用戶控件時，就不把新窗口添加到窗口列表中，而是把列表中的對應窗口的編號及其用戶控件作相應的更新。
26.如權利要求16中所述的系統(tǒng)，其中，對話用戶控件的處理的順序以它們的類型為根據(jù)，其中，Combo框對話用戶控件首先被處理，接著是編輯欄，接著是按鈕用戶控件，在按鈕用戶控件中，最可能導致終止的那些按鈕用戶控件被最后處理。
27.如權利要求16中所述的系統(tǒng)，其中，用戶控件包括菜單項，并且其中所述控制器通過向目標應用程序進程發(fā)送一個命令消息來模擬在某特定菜單項上的點擊，將命令id作為參數(shù)傳送。
28.如權利要求16中所述的系統(tǒng)，其中，所述用戶控件包括菜單項和子菜單項，并且其中所述控制器創(chuàng)建一個所有子菜單項列表并通過考慮每個菜單項的名稱及其位置而確定測試菜單項的順序，那些可能導致終止的菜單項在最后被執(zhí)行。
29.在計算機可讀介質上體現(xiàn)的計算機程序，所述程序通過引導計算機執(zhí)行以下步驟而自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程啟動目標應用程序進程；檢測由目標應用程序進程的GUI打開的第一窗口的出現(xiàn)；通過確定窗口中的包括在窗口中發(fā)現(xiàn)的用戶控件列表的內容，處理打開的窗口；按計算機程序估計的順序測試用戶控件，一直到所有的用戶控件都已經(jīng)被測試；然后關閉第一窗口；其中如果測試某特定用戶控件導致窗口在窗口的所有用戶控件已經(jīng)被測試之前就關閉，所述程序進一步引導計算機重新打開窗口，然后，除非要求該特定用戶控件在該窗口的所有用戶控件都被測試后關閉窗口，否則測試除該特定用戶控件以外的用戶控件；并且其中如果測試某特定用戶控件導致第二窗口打開，所述程序進一步引導所述計算機確定第二窗口的內容，包括用戶控件列表，并測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試，關閉第二窗口，然后繼續(xù)對第一窗口的處理。
30.如權利要求29中所述的計算機程序，其中，在各個用戶控件被測試之后，所述程序引導所述計算機枚舉系統(tǒng)窗口，確定在所枚舉的系統(tǒng)窗口中是否已經(jīng)有因多個新的窗口被打開而產(chǎn)生的變化，確定該多個新窗口之間是否存在父子關系，如果存在父子關系，則在處理父窗口之前處理子窗口，然后繼續(xù)處理第一窗口。
31.如權利要求29中所述的計算機程序，其中，完成測試用戶控件的步驟時將有可能導致終止的用戶控件識別出來并在較小可能導致終止的用戶控件之后測試。
32.如權利要求29中所述的計算機程序，其中，當需要引出在被懷疑隱藏有病毒的程序中的至少一個病毒活動或獲得被懷疑的病毒的樣本時，執(zhí)行該程序。
全文摘要
公開一種用于自動地測試帶有圖形用戶界面(GUI)的目標應用程序進程的方法，以及用于執(zhí)行存儲在計算機可讀介質上的體現(xiàn)該方法的方法和計算機程序的系統(tǒng)。該方法包括以下計算機執(zhí)行的步驟啟動目標應用程序進程；檢測由目標應用程序進程打開的第一窗口的出現(xiàn)；通過確定第一窗口的包括用戶控件列表的內容，處理第一窗口；測試用戶控件，一直到所有的用戶控件都已經(jīng)被測試，有可能導致終止的用戶控件被識別出來并在較小可能導致終止的用戶控件之后被測試；關閉第一窗口。測試的步驟包括估計用戶控件的最佳執(zhí)行順序和要被輸入到用戶輸入欄的文字的步驟。如果測試某特定用戶控件導致第一窗口在第一窗口的所有用戶控件已經(jīng)被測試之前就關閉，該方法進一步包括的步驟是重新打開第一窗口；除非要求該特定用戶控件在該窗口的所有用戶控件都被測試后關閉第一窗口，否則測試除該特定用戶控件以外的用戶控件。如果測試某特定用戶控件導致第二窗口打開，該方法進一步包括的步驟是確定第二窗口的內容，包括用戶控件列表；測試用戶控件，一直到第二窗口的所有用戶控件都已經(jīng)被測試；關閉第二窗口；繼續(xù)對第一窗口的處理。
文檔編號G06F9/44GK1484790SQ01821745
公開日2004年3月24日 申請日期2001年12月14日 優(yōu)先權日2001年1月4日
發(fā)明者A·塞加爾, A 塞加爾, M·斯威默, げ├, J·-M·博萊 申請人:國際商業(yè)機器公司