本發(fā)明涉及軟件測試技術(shù)領(lǐng)域，特別是一種黑盒回歸測試方法。

背景技術(shù)：

軟件功能是軟件價值的重要體現(xiàn)，軟件功能變更是軟件開發(fā)過程中一項難以避免且經(jīng)常發(fā)生的行為，對于每一次功能變更，都需要通過回歸測試驗證其正確性。特別是對于gui類應(yīng)用軟件，這類軟件采用人機交互方式，為用戶提供了一種快捷、簡便的軟件操作方式，gui類軟件在給用戶帶來直觀、簡便、快捷的同時，其本身所具有的輸入/輸出圖形化、事件驅(qū)動、事件觸發(fā)隨機性、多任務(wù)以及消息傳遞等特性，使軟件功能測試以及回歸測試工作面臨許多新的挑戰(zhàn)。

挑戰(zhàn)1：如何獲取軟件所具有的功能

gui類軟件包含大量的界面，每一個界面中又包含很多菜單和按鈕，由此構(gòu)成不同的軟件功能。對于gui類軟件而言，每一個功能路徑對應(yīng)著一個軟件功能，在測試過程中，至少要覆蓋這些功能路徑。然而，由于軟件功能路徑繁多，僅憑手工方式難以確定被測軟件所具有的全部功能，因此也就無法對軟件功能進行全面、有效的測試。

挑戰(zhàn)2：軟件功能變更及其影響域難以確定

目前，大多數(shù)gui類軟件是采用快速原型方法開發(fā)的，軟件版本變更頻繁，在軟件生存周期內(nèi)，需要進行多次回歸測試，由于gui類軟件功能復(fù)雜，難以用人工方式識別軟件功能變更以及功能變更對軟件其他功能帶來的影響，測試人員只能憑借經(jīng)驗對軟件進行回歸測試，這樣，難免造成回歸測試的重復(fù)、冗余和遺漏，影響回歸測試的質(zhì)量和效率。

挑戰(zhàn)3：如何獲知測試覆蓋情況

gui類軟件采用事件驅(qū)動方式執(zhí)行，用戶通過與控件的交互來觸發(fā)相應(yīng)的事件進而與內(nèi)部代碼及業(yè)務(wù)邏輯發(fā)生交互，因此，傳統(tǒng)測試中的諸如分支覆蓋、語句覆蓋等經(jīng)典的覆蓋準(zhǔn)則很難適用于gui類軟件測試中，無法有效指導(dǎo)測試。另一方面，gui類軟件功能是通過界面體現(xiàn)的，用戶通過點擊界面元素實現(xiàn)軟件功能，因此，如何通過功能覆蓋來衡量測試充分性是測試人員面臨的另一大難題。

挑戰(zhàn)4：如何約簡測試用例

在軟件測試過程中，測試人員需要設(shè)計大量的測試用例，從功能覆蓋的角度而言，這些測試用例難免存在重復(fù)和冗余，即不同測試用例所覆蓋的功能相同，對于這些測試用例，需要進行約簡，以減少測試用例執(zhí)行和維護成本。

挑戰(zhàn)5：如何篩選回歸測試用例

在前一輪的測試過程中，測試人員設(shè)計了大量的測試用例，在回歸測試階段，測試人員需要根據(jù)軟件功能變更及其影響情況，從已有測試用例集中篩選出回歸測試用例，由于缺乏有效的方法，測試人員難以從大量測試用例中篩選出符合要求的回歸測試用例。

近年來，軟件的功能越來越豐富，復(fù)雜度也越來越高。隨之，軟件系統(tǒng)功能測試的測試用例數(shù)成倍增長，執(zhí)行一次全集回歸測試的時間大幅度增加，已經(jīng)成為影響產(chǎn)品快速發(fā)布的重要因素之一。尤其在升級維護項目中，需求一般來源于客戶，具有需求變化快、時間要求緊、絕大部分代碼屬于繼承等特點，原有的窮舉所有測試用例的測試策略存在的周期長、效率低的問題愈加凸顯。憑經(jīng)驗選擇部分子集進行回歸測試，雖然可以大幅度的減少測試時間，但是測試質(zhì)量無法保證，存在很大的漏測、重復(fù)測風(fēng)險。

回歸測試優(yōu)化技術(shù)的重點是如何選擇有效的回歸測試集來保證測試有效性并提高測試效率。如何平衡成本與風(fēng)險，業(yè)內(nèi)進行了眾多優(yōu)化技術(shù)研究，大部分都集中在對每一個測試需求對應(yīng)的多個測試用例約簡技術(shù)上，例如粒子群優(yōu)化算法、啟發(fā)式算法、遺傳算法、基于數(shù)據(jù)依賴及控制依賴的用例選擇方法等，對測試范圍優(yōu)化技術(shù)鮮有涉及。

但上述測試方法及裝置存在兩點問題：一是，對系統(tǒng)測試者的能力要求很高，或者需要掌握用戶的使用場景，或者需要對被測軟件的設(shè)計非常了解，清楚了解每個測試用例在代碼中的執(zhí)行路徑，這是大多數(shù)系統(tǒng)測試人員都無法掌握的。二是，對測試環(huán)境和測試資源的要求較高，尤其是嵌入式系統(tǒng)，測試資源緊張、測試手段匱乏，很難實施。

中國發(fā)明專利申請cn106354631a公開了一種快速軟件系統(tǒng)回歸測試的方法，包括：根據(jù)代碼差異以及使用關(guān)系，獲得全部變化影響的用戶接口全集，確定系統(tǒng)回歸測試黑盒測試用例范圍；根據(jù)變化單元的復(fù)雜度及用戶接口使用變化單元的情況，計算用戶接口的優(yōu)先級，確定黑盒測試用例的執(zhí)行順序；依據(jù)上述測試范圍和優(yōu)先級順序?qū)嵤y試。

目前，在回歸測試領(lǐng)域，有代表性的黑盒回歸測試工具是mercuryinteractive公司的winrunner和ibmhpquicktestprofessional(qtp)。這些工具采用捕獲/回放技術(shù)，通過捕獲測試人員的操作，生成測試腳本。在回歸測試時，通過回放測試腳本程序，對修改后的軟件進行測試。這種方法采用的是重新運行所有測試用例的策略，不能針對軟件的修改情況選擇回歸測試用例，難免執(zhí)行不必要的測試用例，并且，在回放測試腳本時，由于軟件版本的變更，經(jīng)常導(dǎo)致腳本程序中斷，測試人員需要花費大量的時間調(diào)試測試腳本，從而，大大降低了測試效率，因此，盡管這些工具有很獨特的理念，但實際使用效果不佳。此外，這類工具不具備功能變更標(biāo)識、功能變更影響分析、測試用例優(yōu)化以及回歸測試用例優(yōu)選等功能，不能滿足回歸測試需要。

另外一個在回歸測試領(lǐng)域研究較多的是基于代碼的回歸測試，這類方法主要是通過分析代碼，找出受代碼改動影響的代碼部分，這部分代碼是回歸測試時需要重新測試的代碼。這類方法只適合于白盒測試，由于軟件代碼與軟件功能不存在直接的一一對應(yīng)關(guān)系，因此，這類方法不適合于對軟件進行功能回歸即黑盒回歸測試。

技術(shù)實現(xiàn)要素：

本發(fā)明需要解決的技術(shù)問題是提供一種快速、準(zhǔn)確、高效進行黑盒回歸測試的方法和系統(tǒng)。

為解決上述技術(shù)問題，本發(fā)明的一種黑盒回歸測試方法，包括以下步驟，

步驟s101：源代碼解析，通過類型解析和對源代碼的詞法、語法分析得到代碼的語法樹和類型系統(tǒng)；

步驟s102：界面元素分析，掃描源代碼抽象語法樹，以窗口類定義為基本單元，分析被測軟件的界面構(gòu)成，形成界面元素樹模型；

步驟s103：交互關(guān)系分析，掃描源代碼抽象語法樹，并依據(jù)所使用的類型系統(tǒng)對調(diào)用邏輯、事件流進行分析，形成被測軟件界面元素調(diào)用關(guān)系模型；

步驟s104：測試執(zhí)行過程跟蹤，捕獲用例執(zhí)行過程中所輸入的數(shù)據(jù)以及點擊的界面元素，形成用例執(zhí)行路徑數(shù)據(jù)；

步驟s105：用例覆蓋分析，將用例執(zhí)行數(shù)據(jù)與界面模型進行匹配，得到每個用例執(zhí)行后被覆蓋的界面元素和路徑，并以圖形方式顯示于界面上；

步驟s106：測試用例約簡，分析一組用例所覆蓋的界面元素和路徑，采用基于調(diào)用路徑和基于界面元素覆蓋數(shù)量兩種算法剔除其中冗余的測試用例，形成測試用例集；

步驟s107：功能差異檢測，通過對兩個軟件版本的靜態(tài)分析結(jié)果進行分析，找出兩個版本間的ui差異和ui變更位置；

步驟s108：功能變更影響分析，依據(jù)找到的變更點，采用回溯迭代算法，在界面元素靜態(tài)結(jié)構(gòu)模型上查找依賴項，形成從變更點出發(fā)的變更影響范圍即影響域；

步驟s109：回歸測試用例篩選：以變更影響域為目標(biāo)函數(shù)，采用覆蓋的變更功能優(yōu)先、關(guān)鍵度優(yōu)先以及路徑長度優(yōu)先策略，從約簡后的測試用例集中查找出能夠覆蓋變更影響域的最少個數(shù)測試用例；

步驟s110：影響域覆蓋分析，依據(jù)篩選出的回歸測試用例所能夠覆蓋的變更影響域，找出尚未被覆蓋的變更影響域。

進一步的，所述步驟s101源代碼解析中如果代碼為c#語言，將代碼的邏輯結(jié)構(gòu)與代碼所述的類型系統(tǒng)相關(guān)聯(lián)，所述類型系統(tǒng)中包含被測軟件自定義的類型、引用類庫的類型以及框架自身的類型，依據(jù)其關(guān)聯(lián)關(guān)系識別出語法樹的語義信息。

進一步的，所述步驟s104測試執(zhí)行過程跟蹤具體還包括以下步驟，

步驟s141：執(zhí)行窗口調(diào)用樹圖構(gòu)建；

步驟s142：界面控件捕獲。

更進一步的，所述步驟s142中的界面控件包括按鈕、編輯框、菜單項、listview、標(biāo)簽、工具欄按鈕、tab選項卡、列表框和combobox。

進一步的，所述步驟s106測試用例約簡具體包括以下步驟，

步驟s161：關(guān)鍵用例處理；

步驟s162：用例篩選；

步驟s163：結(jié)果提交。

進一步的，所述步驟s108功能變更影響分析包括基于功能圖的變更影響分析和基于調(diào)用關(guān)系的變更影響分析。

進一步的，所述步驟s109測試用例篩選采用覆蓋的變更功能優(yōu)先、關(guān)鍵度優(yōu)先、路徑長度優(yōu)先三種原則，從約簡后的測試用例集中，挑選出個數(shù)最少的測試用例。

采用上述后方法后，本發(fā)明有效解決回歸測試中的如下問題：

1、軟件功能自動獲??；

2、軟件功能變更標(biāo)識及變更影響分析；

3、測試覆蓋獲?。?/p>

4、測試用例約簡；

5、回歸測試用例篩選。

本發(fā)明能夠有效避免回歸測試的重復(fù)、冗余和遺漏，大大提高回歸測試的充分性、有效性和測試效率。

附圖說明

下面結(jié)合附圖和具體實施方式對本發(fā)明作進一步詳細的說明。

圖1為本發(fā)明黑盒回歸測試功能結(jié)構(gòu)示意圖。

圖2為本發(fā)明源代碼解析工作流程圖。

圖3為本發(fā)明匹配關(guān)系示意圖。

圖4為本發(fā)明依賴關(guān)系模型圖。

圖5為本發(fā)明按鈕種類示意圖。

圖6為本發(fā)明按鈕抽象操作流程圖。

圖7為本發(fā)明查找窗口示意圖。

圖8為本發(fā)明文本框抽象操作流程圖。

圖9為本發(fā)明菜單窗口示意圖。

圖10為本發(fā)明菜單抽象操作流程圖。

圖11為本發(fā)明測試用例優(yōu)化處理流程圖。

圖12為本發(fā)明功能結(jié)構(gòu)變更影響示意圖。

圖13為本發(fā)明調(diào)用關(guān)系變更影響示意圖。

圖14為本發(fā)明回歸測試用例優(yōu)選處理流程。

圖15為本發(fā)明學(xué)生管理系統(tǒng)程序主界面示意圖。

圖16為本發(fā)明界面元素及交互關(guān)系分析結(jié)果示意圖。

圖17為本發(fā)明“登錄系統(tǒng)”測試執(zhí)行跟蹤示意圖。

圖18為本發(fā)明測試用例覆蓋路徑示意圖。

圖19為本發(fā)明測試用例優(yōu)化結(jié)果示意圖。

圖20為本發(fā)明功能差異檢測結(jié)果示意圖。

圖21為本發(fā)明變更影響分析結(jié)果示意圖。

具體實施方式

如圖1所示，本發(fā)明的一種黑盒回歸測試方法，包括以下步驟，

步驟s101：源代碼解析，通過類型解析和對源代碼的詞法、語法分析得到代碼的語法樹和類型系統(tǒng)。如圖2所示，當(dāng)代碼為c#語言時，由于c#語言是面向?qū)ο笳Z言，要對代碼進行進一步分析，需要將代碼的邏輯結(jié)構(gòu)(ast)與代碼所處的類型系統(tǒng)相關(guān)聯(lián)，該類型系統(tǒng)中包含被測軟件自定義的類型、引用類庫的類型以及框架自身的類型，依據(jù)其關(guān)聯(lián)關(guān)系識別出語法樹的語義信息。本方案依據(jù)程序集依賴關(guān)系構(gòu)建類型系統(tǒng)全集，根據(jù)語法樹節(jié)點所定義的元素類型，以全命名查找對應(yīng)的類型系統(tǒng)元素，建立永久關(guān)聯(lián)并進行存儲。通過解析方法查詢兩者關(guān)聯(lián)關(guān)系，產(chǎn)生源代碼抽象語法樹、類型系統(tǒng)范圍及關(guān)聯(lián)數(shù)據(jù)庫。

步驟s102：界面元素分析，掃描源代碼抽象語法樹，以窗口類定義為基本單元，分析被測軟件的界面構(gòu)成，形成界面元素樹模型。在建立代碼邏輯結(jié)構(gòu)和類型系統(tǒng)基礎(chǔ)上，通過遍歷語法樹以樹結(jié)構(gòu)模板識別方法查找界面元素定義及屬性設(shè)置。最終形成全集數(shù)據(jù)模型。

依據(jù)ast所表示的語法邏輯和類型系統(tǒng)，在代表ui元素的類定義中分析界面元素組織關(guān)系，系統(tǒng)定義模式庫表示要在語法樹上識別的特征模板，通過匹配引擎在迭代語法樹的過程中抽取界面元素的定義、屬性設(shè)置和隸屬關(guān)系信息，形成界面元素集合并建立隸屬關(guān)系。

模式庫中的一條模式規(guī)則由一棵節(jié)點有序的樹形結(jié)構(gòu)表示，依據(jù)有序樹匹配理論在抽象語法樹上進行匹配，規(guī)則樹是由規(guī)則節(jié)點與特定規(guī)則關(guān)聯(lián)形成的樹形結(jié)構(gòu)，規(guī)則節(jié)點定義語法樹節(jié)點的屬性匹配規(guī)則，用于對語法樹節(jié)點的匹配。如圖3所示，節(jié)點之間的關(guān)系分為三種情形：1.存在于子層：表示ast片段中以某個子節(jié)點為根的子樹完全與規(guī)則匹配；2.存在于左子樹：表示ast片段某節(jié)點下第一個節(jié)點子樹中存在與規(guī)則匹配的節(jié)點，3.存在于子樹：表示ast片段某節(jié)點下全部子樹中存在與規(guī)則匹配的節(jié)點。

模式庫中的一條模式規(guī)則由一棵節(jié)點有序的樹形結(jié)構(gòu)表示，依據(jù)有序樹匹配理論在抽象語法樹上進行匹配，規(guī)則樹是由規(guī)則節(jié)點與特定規(guī)則關(guān)聯(lián)形成的樹形結(jié)構(gòu)，規(guī)則節(jié)點定義語法樹節(jié)點的屬性匹配規(guī)則，用于對語法樹節(jié)點的匹配。節(jié)點之間的關(guān)系分為三種情形：1.存在于子層：表示ast片段中以某個子節(jié)點為根的子樹完全與規(guī)則匹配；2.存在于左子樹：表示ast片段某節(jié)點下第一個節(jié)點子樹中存在與規(guī)則匹配的節(jié)點，3.存在于子樹：表示ast片段某節(jié)點下全部子樹中存在與規(guī)則匹配的節(jié)點。

步驟s103：交互關(guān)系分析，掃描源代碼抽象語法樹，并依據(jù)所使用的類型系統(tǒng)對調(diào)用邏輯、事件流進行分析，形成被測軟件界面元素調(diào)用關(guān)系模型。在通過語法樹迭代遍歷語法樹獲得界面元素定義的同時，識別界面事件的定義-引用關(guān)系，在事件和處理函數(shù)之間建立連接，分析類型、方法間的調(diào)用關(guān)系，通過控制流分析方法在界面元素間建立引用關(guān)系，形成依賴關(guān)系模型。利用有向圖建立窗口、窗口元素、元素間交互關(guān)系，窗口及元素用有向圖中的節(jié)點表示，交互及關(guān)聯(lián)關(guān)系用有向邊來表示，其類圖用圖4表示。

步驟s104：測試執(zhí)行過程跟蹤，捕獲用例執(zhí)行過程中所輸入的數(shù)據(jù)以及點擊的界面元素，形成用例執(zhí)行路徑數(shù)據(jù)。測試執(zhí)行跟蹤主要用于捕獲測試人員所做的操作，例如，點擊的菜單、按鈕、鍵盤輸入的數(shù)據(jù)等。通過捕獲的這些操作信息，測試人員可以準(zhǔn)確掌握測試用例對軟件界面元素的覆蓋情況。具體包括以下步驟，

步驟s141：執(zhí)行窗口調(diào)用樹圖構(gòu)建；為了實現(xiàn)上述目的，本專利中綜合采用鉤子和api函數(shù)，在測試人員執(zhí)行樣本測試用例過程中構(gòu)建執(zhí)行窗口調(diào)用樹圖，構(gòu)建算法如下，執(zhí)行結(jié)束后，w是執(zhí)行窗口調(diào)用樹圖的結(jié)點集合，e是執(zhí)行窗口調(diào)用樹圖的邊的集合。

步驟s142：界面控件捕獲，界面控件是軟件界面的組成要素，本專利通過對常用界面元素特性分析，給出了以下幾種常見控件的抽象操作方法。

1)按鈕的抽象操作；

2)編輯框的抽象操作；

3)菜單項的抽象操作；

4)listview抽象操作；

5)標(biāo)簽的抽象操作；

6)工具欄按鈕的抽象操作；

7)tab選項卡的抽象操作；

8)列表框的抽象操作；

9)combobox的抽象操作；

除了這幾種常用控件外，工具還對對話框的彈出等gui軟件的狀態(tài)變化進行抽象操作，下面對部分重要控件的抽象操作進行詳細介紹。

1)按鈕點擊的抽象操作

當(dāng)判斷截獲到一條消息并且控件的類名為“button”時，有可能是一個標(biāo)準(zhǔn)的按鈕控件，還有可能是checkbox或radiobutton，三種控件的區(qū)別如圖5所示。

對于checkbox或radiobutton控件，用戶可以選擇或不選擇，將它的值在真與假之間改變。checkbox和radiobutton控件有一個名為checked的屬性，需要檢查checked屬性的值，才能對按鈕的狀態(tài)進行具體描述。

radiobutton和checkbox有一些不同點，第一、radiobutton控件以組的形式出現(xiàn)，同一組內(nèi)只能有一個且必須有一個選項選中，選中即控件的checked屬性為真；而checkbox控件可以以組的形式出現(xiàn)，也可以單獨出現(xiàn)，可以多個選項同時選中或均不選中；第二、radiobutton只要被單擊，所點擊選項的checked屬性就變成真，即使radiobutton的屬性已經(jīng)為真了，單擊后它的屬性依然為真，而checkbox控件屬性值在控件被單擊后，會從假變?yōu)檎?，或從真變?yōu)榧?。針對按鈕控件，其抽象操作流程如圖6所示。

判斷按鈕的類型的處理具體描述為：

利用getwindowlong(hwnd,nindex)函數(shù)判斷按鈕的具體類型，函數(shù)有兩個參數(shù)：hwnd：窗口或控件的句柄；nindex：指定要檢索的基于0的偏移量，可以設(shè)置為gwl_exstyle代表獲得擴展窗口風(fēng)格、gwl_style代表獲得窗口風(fēng)格、gwl_hwndparent代表如果父窗口存在，獲得父窗口句柄。為了判斷具體的控件類型，使用的是gwl_style窗口風(fēng)格標(biāo)識，再將獲取值同0x0000ffff進行與操作，就可以判定所操作控件是bs_autocheckbutton或bs_autoradiobutton，然后再根據(jù)控件具體類型進行抽象操作。

2)文本框的抽象操作

由于對編輯框的操作后，收到的消息只是文本框的內(nèi)容，例如圖7所示記事本程序“查找”窗口，編輯框輸入內(nèi)容“測試”后，如果只是輸出記錄“在文本框中輸入內(nèi)容‘測試’”，因為沒有獲取編輯框的標(biāo)簽，無法完整表達所操作的含義，這就需要對編輯框進行一個獲取標(biāo)簽信息的特殊處理。對文本框控件的抽象操作處理流程如圖8所示。

如何獲取文本框的標(biāo)簽具體描述為：

1、編輯框編輯結(jié)束時查找文本框的標(biāo)簽坐標(biāo)時，首先需要利用win32api函數(shù)getwindowrect(inthwnd,refrt)找到文本框的左側(cè)和底側(cè)的坐標(biāo)值，其中hwnd代表控件的句柄，rt代表一個結(jié)構(gòu)，結(jié)構(gòu)由四個元素組成，分別是控件的上側(cè)、下側(cè)、左側(cè)、右側(cè)的坐標(biāo)值。其功能是將句柄為hwnd的控件底側(cè)、左側(cè)、上側(cè)、右側(cè)的坐標(biāo)拷貝到rt結(jié)構(gòu)中，通過取rt結(jié)構(gòu)的參數(shù)值即可。

2、根據(jù)經(jīng)驗文本框的標(biāo)簽位置一般在其左側(cè)或者上側(cè)，首先從控件的左側(cè)開始查詢，取出所操作文本框控件的左側(cè)和底側(cè)坐標(biāo)值，按照x坐標(biāo)遞減的順序，尋找控件類名是“l(fā)abel”的控件，設(shè)置遞減的長度，如果沒有，再取出所操作文本框控件的上側(cè)和左側(cè)坐標(biāo)值，再按照y坐標(biāo)值遞減的順序進行查找，同樣需要設(shè)置遞減的長度，直到找到“l(fā)abel”控件，將其標(biāo)簽屬性標(biāo)識文本框控件，對文本框進行抽象操作。

3)菜單項的選擇抽象操作

菜單的結(jié)構(gòu)是層次型構(gòu)造，如圖9所示，最上一層“文件”、“編輯”、“格式”的菜單被稱為主菜單項，主菜單項在前端的接口中是可見的，下一層的菜單只有單擊主菜單之后才會顯示，其中“新建”、“打開”等菜單項，都被稱為子菜單。子菜單也可以有自己的子菜單，每一個菜單的條目都會有唯一的菜單句柄，用來唯一標(biāo)識所點擊的菜單條目。對菜單控件的抽象操作處理流程如圖10所示。

對菜單項抽象操作具體描述為：

1、當(dāng)點擊主菜單時，通過getmenu(inthwin)函數(shù)返回菜單句柄，其中hwnd代表窗口的句柄；

2、再利用menuitemfrompoint(inthwin,inthmenu,pointpt)函數(shù)得到所點擊主菜單選項在主菜單中的位置索引，其中hwin代表窗口的句柄，hmenu代表菜單的句柄，pt代表當(dāng)前點擊的坐標(biāo)；

3、調(diào)用getmenustring(inthmenu,inttopmenuindex,inttopmenutext,128,mf_byposition)函數(shù)獲取主菜單的文本，其中hpremenu代表菜單的句柄，topmenuindex代表點擊主菜單項的索引，topmenutext代表得到菜單文本的字符串，mf_byposition代表獲取類型標(biāo)識；

4、此時子菜單打開，如果用戶繼續(xù)點擊子菜單項，調(diào)用getsubmenu(inthpremenu,inttopmenuindex)函數(shù)獲取子菜單項句柄，其中hpremenu代表菜單的句柄，topmenuindex代表點擊主菜單的索引；menuitemfrompoint(inthwin,inthsubmenu,pointpt)函數(shù)獲取子菜單索引，其中hwin代表主菜單的句柄，hsubmenu代表子菜單的句柄，pt代表鼠標(biāo)點擊的坐標(biāo)；

5、調(diào)用getmenustring(inthsubmenu,intindexsub,intsubmenutext,128,mf_bycommand)函數(shù)獲取子菜單文本，其中hsubmenu代表子菜單的句柄，indexsub代表選擇的子菜單項的索引，submenutext代表的得到子菜單項文本的字符串，進而結(jié)合主菜單對菜單項操作進行抽象處理。

步驟s105：用例覆蓋分析，將用例執(zhí)行數(shù)據(jù)與界面模型進行匹配，得到每個用例執(zhí)行后被覆蓋的界面元素和路徑，并以圖形方式顯示于界面上。

步驟s106：測試用例約簡，分析一組用例所覆蓋的界面元素和路徑，采用基于調(diào)用路徑和基于界面元素覆蓋數(shù)量兩種算法剔除其中冗余的測試用例，形成測試用例集。

由于測試用例設(shè)計的局限性，從功能覆蓋的角度而言，難免存在重復(fù)或冗余的測試用例，這類測試用例對測試覆蓋是沒有貢獻的，需要將其剔除，以減少回歸測試執(zhí)行和回歸測試用例維護工作量。

本發(fā)明中提出了基于調(diào)用路徑和覆蓋路徑兩種測試用例優(yōu)化策略，采用基于程序路徑和功能路徑的啟發(fā)式貪心算法，對測試用例進行約簡，有效剔除了重復(fù)和冗余的測試用例，大大減少了測試用例的維護和執(zhí)行費用。

依據(jù)測試用例關(guān)鍵度和覆蓋ui元素及調(diào)用路徑的對應(yīng)關(guān)系來完成測試用例集的約簡工作，通過及時判斷測試用例對ui元素節(jié)點的覆蓋情況，系統(tǒng)在得到每個測試用例所覆蓋的界面元素和執(zhí)行路徑后，采用基于調(diào)用路徑和基于界面元素覆蓋數(shù)量兩種算法剔除其中冗余和重復(fù)的測試用例，從而在保留關(guān)鍵測試用例基礎(chǔ)上盡可能地收縮測試用例集，完成用例優(yōu)化。優(yōu)化分為三個階段進行，即關(guān)鍵測試用例處理及包含冗余檢測階段、測試用例篩選階段和測試用例排序階段，如圖11所示。具體包括以下步驟，

步驟s161：關(guān)鍵用例處理；迭代所有的必要測試用例，對所有被必要測試用例覆蓋的ui元素節(jié)點和調(diào)用路徑進行標(biāo)注；迭代所有測試用例，檢測測試用例覆蓋路徑間的包含關(guān)系，對包含在關(guān)鍵用例中的冗余用例進行標(biāo)注。而后更新剩余測試用例集和未被覆蓋的ui節(jié)點和調(diào)用邊形成覆蓋需求集。

步驟s162：用例篩選；用例篩選。在現(xiàn)有覆蓋需求集和用例集基礎(chǔ)上，對所有剩余用例依據(jù)調(diào)用路徑和基于界面元素覆蓋數(shù)量兩種算法進行關(guān)鍵度排序。在調(diào)用路徑覆蓋優(yōu)先原則下，依據(jù)用例覆蓋待測有調(diào)用關(guān)系向邊數(shù)量進行由高到底排序，在界面元素覆蓋數(shù)量優(yōu)先原則下，依據(jù)用例覆蓋待測ui節(jié)點的數(shù)量進行由高到底排序，選取關(guān)鍵度最高的用例作為候選用例，更新測試用例集和剩余未被覆蓋的ui節(jié)點和調(diào)用邊，重復(fù)上述步驟，直到候選測試用例集為空或所有剩余測試用例關(guān)鍵度為0為止。

步驟s163：結(jié)果提交，對所有關(guān)鍵測試用例也依據(jù)兩種關(guān)鍵度評價方法執(zhí)行貪心算法進行排序，合并已選測試用例依次排序，順序設(shè)置執(zhí)行優(yōu)先級，輸出被優(yōu)化后的測試用例集，綜合用例集覆蓋范圍，提取未能覆蓋的功能模型范圍。

步驟s107：功能差異檢測，通過對兩個軟件版本的靜態(tài)分析結(jié)果進行分析，找出兩個版本間的ui差異和ui變更位置。

通過在ui結(jié)構(gòu)差異和ui交互差異兩個方面對新舊兩個版本軟件進行檢測，在全局功能交互模型中標(biāo)識變化點。

以有向圖表示的功能交互模型中抽取界面元素節(jié)點。按照包含關(guān)系有向邊抽取ui元素和其間的連接關(guān)系，以樹形結(jié)構(gòu)表示系統(tǒng)ui構(gòu)成，建模系統(tǒng)功能結(jié)構(gòu)模型；按照調(diào)用關(guān)系有向邊抽取交互模型子圖，用來表示ui元素間的功能交互模型。我們通過編輯距離方法比較兩種結(jié)構(gòu)之間的差異，通過計算將原版本結(jié)構(gòu)模型映射為新版本結(jié)構(gòu)模型的變更操作序列，揭示兩個版本間的功能結(jié)構(gòu)變更和交互變更，并在新舊版本中進行標(biāo)注形成變更域。

系統(tǒng)使用關(guān)聯(lián)關(guān)系矩陣存儲系統(tǒng)ui元素功能結(jié)構(gòu)和交互關(guān)系有向圖，定義新增、刪除、變更三種基本操作，通過計算將原版本功能結(jié)構(gòu)、交互關(guān)系有向圖轉(zhuǎn)換為新版本有向圖的最小代價，將相應(yīng)的編輯操作映射到新舊版本的結(jié)構(gòu)和交互模型上，標(biāo)注變更。

系統(tǒng)首先以靜態(tài)分析得到的ui元素節(jié)點的全限定名來進行節(jié)點對齊和屬性比對，生成對應(yīng)節(jié)點間的編輯操作集合；而后對比對比兩個版本間的ui元素差異，映射ui元素節(jié)點的增加、刪除操作；最后對圖中的有向邊連接關(guān)系及其連接屬性進行比對，形成連接關(guān)系間的增加、刪除、修改操作，將上述操作集合并形成操作序列，依據(jù)ui元素差異和屬性差異標(biāo)注功能結(jié)構(gòu)變更、依據(jù)有向邊差異標(biāo)注交互關(guān)系變更。

步驟s108：功能變更影響分析，依據(jù)找到的變更點，采用回溯迭代算法，在界面元素靜態(tài)結(jié)構(gòu)模型上查找依賴項，形成從變更點出發(fā)的變更影響范圍即影響域。

系統(tǒng)綜合基于功能圖的變更影響分析和基于調(diào)用關(guān)系(控制流)的變更影響分析結(jié)果，合并生成變更影響域。

1)基于功能圖的變更影響分析。本系統(tǒng)采用靜態(tài)分析技術(shù)獲得被測軟件功能結(jié)構(gòu)，在被測軟件交互模型中從窗口元素出發(fā)按照ui元素包含關(guān)系可抽取ui結(jié)構(gòu)，結(jié)構(gòu)中的根節(jié)點為每一個程序窗口，下級節(jié)點構(gòu)成控件樹，在功能結(jié)構(gòu)圖中，用元素間節(jié)點間的有向邊表示包含關(guān)聯(lián)，方向由父節(jié)點指向子節(jié)點，我們認為子節(jié)點屬性的變更會影響父節(jié)點功能的完成，即，在軟件功能圖中ui節(jié)點屬性和子樹結(jié)構(gòu)的變更會沿有向邊的反方向傳遞。系統(tǒng)首先在結(jié)構(gòu)樹中標(biāo)注變更檢測得到的功能結(jié)構(gòu)變更，依據(jù)上述傳播規(guī)律沿有向邊上溯到根節(jié)點，沿途標(biāo)注變更影響路徑，形成結(jié)構(gòu)變更影響域。

2)基于調(diào)用關(guān)系的變更影響分析。系統(tǒng)在進行基于代碼的靜態(tài)分析時，生成函數(shù)調(diào)用關(guān)系數(shù)據(jù)結(jié)構(gòu)，我們把依賴關(guān)系模型表示為一個有向圖，函數(shù)作為該有向圖的節(jié)點，每一個函數(shù)調(diào)用表達式作為連接兩個函數(shù)節(jié)點的有向邊，其方向由調(diào)用函數(shù)指向被調(diào)用函數(shù)，整個函數(shù)調(diào)用有向圖描述了被測工程的函數(shù)調(diào)用關(guān)系；通過事件映射模式規(guī)則識別出界面元素及事件處理函數(shù)間的映射關(guān)系，與函數(shù)調(diào)用合成形成控制依賴有向圖。靜態(tài)分析時抽取了界面元素對象的定義-引用關(guān)系，通過綜合界面元素定義-引用對(d-upair)，在函數(shù)調(diào)用中識別對界面元素對象的引用，從而在控制流節(jié)點(函數(shù))中關(guān)聯(lián)受影響的界面元素，鏈接形成界面元素間的引用關(guān)系，界面元素間的引用關(guān)系與控制流方向相同。我們認為界面元素節(jié)點的變更，會沿控制流雙向傳遞，系統(tǒng)通過函數(shù)調(diào)用有向邊和事件關(guān)聯(lián)有向邊，由變更點出發(fā)追溯至界面元素節(jié)點，沿途標(biāo)注調(diào)用關(guān)系影響域。如圖12和圖13所示，系統(tǒng)最終在交互模型中合成兩種方式所標(biāo)注的節(jié)點和有向邊形成變更影響域，標(biāo)注受變更影響的所有ui元素。

步驟s109：測試用例篩選：以變更影響域為目標(biāo)函數(shù)，采用覆蓋的變更功能優(yōu)先、關(guān)鍵度優(yōu)先以及路徑長度優(yōu)先策略，從約簡后的測試用例集中查找出能夠覆蓋變更影響域的最少個數(shù)測試用例；

步驟s110：影響域覆蓋分析，依據(jù)篩選出的回歸測試用例所能夠覆蓋的變更影響域，找出尚未被覆蓋的變更影響域。

采用覆蓋的變更功能優(yōu)先、關(guān)鍵度優(yōu)先、路徑長度優(yōu)先三種原則，從約簡后的測試用例集中，挑選出個數(shù)最少的測試用例。其工作流程如圖14所示。首先，對原有測試用例進行篩選，參照變更域中控制流路徑，對因路徑變更不能抵達變更點所在ui元素的測試用例進行標(biāo)注，在候選用例集中排除該用例。而后，利用剩余用例構(gòu)成候選用例集進行優(yōu)選：將回歸測試用例集置為為空，且其測試覆蓋度為0；根據(jù)測試人員的選擇，依據(jù)變更功能優(yōu)先、關(guān)鍵度優(yōu)先、路徑長度優(yōu)先的原則計算單個測試用例對變更影響域覆蓋的貢獻，據(jù)此對候選用例進行排序，選取覆蓋貢獻大于0的測試用例中，貢獻最大的測試用例加入回歸測試用例集；對變更域節(jié)點進行覆蓋標(biāo)注，計算總體覆蓋貢獻；余下用例重復(fù)進行上一步判斷，直到余下用例均計算完畢為止；最終提交回歸測試用例集，及變更域覆蓋數(shù)據(jù)集，對未能覆蓋的變更域節(jié)點和路徑進行標(biāo)注，提示進行新用例設(shè)計。

上述算法中依據(jù)覆蓋貢獻對候選用例集的排序直接影響了最終測試用例篩選的結(jié)果，相關(guān)排序指標(biāo)的計算方式為：

變更功能：整個用例路徑上覆蓋變更影響域中未覆蓋變更點的個數(shù)，用來描述單個測試用例對變更影響域覆蓋的貢獻；

路徑關(guān)鍵度：使用在靜態(tài)分析中的到的ui元素依賴關(guān)系有向圖中ui節(jié)點的扇入數(shù)與扇出數(shù)的總和，結(jié)合測試需求來標(biāo)注單個元素的關(guān)鍵度，整個用例的關(guān)鍵度是用例所覆蓋變更域內(nèi)尚未覆蓋的變更點的關(guān)鍵度的總和，用來描述單個測試用例對變更影響域關(guān)鍵功能點覆蓋的貢獻。

路徑長度：標(biāo)注測試用例路徑的長度，用來度量測試用例執(zhí)行的大小及用例的綜合測試能力，在覆蓋度相同的情況下優(yōu)先選擇路徑長度大的測試用例。

實施方式一：

下面以vsc#語言開發(fā)的學(xué)生管理系統(tǒng)程序為例，具體說明如何通過本發(fā)明實現(xiàn)黑盒回歸測試。示例程序輸入界面如圖15所示。

1、界面元素及交互關(guān)系分析

根據(jù)本發(fā)明步驟s101源代碼解析、步驟s102界面元素分析和步驟s103交互關(guān)系分析，通過對軟件源代碼進行分析，可得到界面中的元素，即軟件窗口組成、窗口調(diào)用關(guān)系、控件類型、名稱等屬性，如圖16所示。

2、測試執(zhí)行跟蹤

以“登錄系統(tǒng)”功能為例，用戶界面如圖17所示。通過跟蹤用戶執(zhí)行步驟，得出用戶對“用戶名”、“密碼”文本框進行了輸入操作，對“登錄”按鈕進行了點擊操作，如圖17所示。測試操作覆蓋了流程涉及“登錄”界面，如圖18所示。

3、測試用例約簡

采用步驟s106測試用例約簡中的算法，通過測試用例覆蓋路徑、界面、控件等的比對，找出冗余測試用例，得出測試用例約簡結(jié)果，如圖19所示。

4、功能差異檢測及變更影響分析

采用步驟步驟s107功能差異檢測和步驟s108功能變更影響分析中的算法，通過對軟件回歸版本和基線版本的對比，得出軟件功能差異，如圖20所示。并且在軟件功能調(diào)用圖中顯示變更影響分析，其中黃色標(biāo)注修改的部分，藍色標(biāo)注新增的部分，如圖21所示。

雖然以上描述了本發(fā)明的具體實施方式，但是本領(lǐng)域熟練技術(shù)人員應(yīng)當(dāng)理解，這些僅是舉例說明，可以對本實施方式作出多種變更或修改，而不背離本發(fā)明的原理和實質(zhì)，本發(fā)明的保護范圍僅由所附權(quán)利要求書限定。