專利名稱：一種基于事件模擬的用戶界面測試方法及裝置的制作方法
一種基于事件模擬的用戶界面測試方法及裝置
技術(shù)領(lǐng)域：
本發(fā)明涉及用戶界面測試領(lǐng)域，特別是涉及一種基于事件模擬的用戶界面測試方 法及裝置。
背景技術(shù)：
隨著互聯(lián)網(wǎng)的廣泛應(yīng)用，網(wǎng)站上的網(wǎng)頁的內(nèi)容、布局、樣式常常需要變動，這導(dǎo)致 在項目的升級過程中，由前端用戶界面的變動而引入的新缺陷(BUG)數(shù)量越來越多，在其 他的軟件產(chǎn)品中也同樣存在這樣的問題，即用戶界面的修改會導(dǎo)致項目的新BUG，因此需要 有一種比較好的測試方法可以對用戶界面進(jìn)行有效測試。目前已有的測試工具，主要有兩種類型第一種類型是簡單模擬鼠標(biāo)軌跡，即測試 腳本為鼠標(biāo)經(jīng)過的坐標(biāo)軌跡和在軌跡上的點擊。在這種方式下，當(dāng)用戶界面布局有所改變 的時候，鼠標(biāo)點擊的軌跡也需要隨之變化，所以測試腳本就得完全重做。第二種類型是基于 事件模擬對用戶界面進(jìn)行測試，即模擬在用戶界面的控件上發(fā)生的各種事件。通過判斷用 戶界面的控件對模擬的事件是否能夠正常響應(yīng)，就能夠發(fā)現(xiàn)用戶界面是否存在錯誤。由于 這種方式針對的測試對象是控件，而控件是可以隨著布局改變的，這種方式可以有效避免 用戶界面的布局發(fā)生改變后，測試腳本必須完全重做的情況發(fā)生，但在現(xiàn)有技術(shù)的這種方 式下，基于事件的模擬僅是簡單模擬，即只是在某個需要測試的控件上模擬一個簡單的瀏 覽器事件，卻不考慮事件與事件之間、事件與控件之間、控件與控件之間的關(guān)聯(lián)性，例如在 按鈕A上模擬一個單擊(click)事件，再在按鈕B上模擬一個單擊事件，這兩次模擬是割 裂開的，而實際上，鼠標(biāo)不可能憑空從按鈕A飛到按鈕B，在這兩次單擊事件之間，一定還發(fā) 生了鼠標(biāo)移動事件，由于不考慮事件與事件之間、事件與控件之間、控件與控件之間的關(guān)聯(lián) 性，很可能會出現(xiàn)測試的事件沒有發(fā)生錯誤，而與測試事件相關(guān)的其他事件卻發(fā)生錯誤但 正好沒有被測試到的情況。以上例來說，有可能對按鈕A的單擊與對按鈕B的單擊都沒有 出錯，但是從按鈕A移動到按鈕B時，用戶界面卻出現(xiàn)了錯誤的響應(yīng)，由于沒有測試這種情 況，所以也就無法發(fā)現(xiàn)這個錯誤。僅靠人工去考慮所有需要測試的控件與事件是非常困難 的，很容易發(fā)生遺漏，也就是說，現(xiàn)有技術(shù)的基于事件模擬對用戶界面測試的方法很容易出 現(xiàn)漏測的情況。請參考圖1，圖1為現(xiàn)有技術(shù)中基于事件模擬進(jìn)行用戶界面測試的方法的流程圖。 首先步驟11接收測試用例，測試用例中描述了需要測試的事件以及事件發(fā)生的控件。步驟 12根據(jù)測試用例發(fā)出無邏輯關(guān)系的簡單事件模擬請求，所謂的無邏輯關(guān)系是指每個測試的 事件之間是割裂的。步驟13直接根據(jù)步驟12中的請求調(diào)用上層工作環(huán)境接口創(chuàng)建事件。 步驟14記錄在事件發(fā)生過程中的運行日志。在這種方法下，測試方法本身對測試邏輯是否 合理不做判斷，在什么控件上模擬什么事件，完全由測試人員自行決定，這增加了測試人員 的工作量，也很容易出現(xiàn)漏測的現(xiàn)象。
發(fā)明內(nèi)容為了解決現(xiàn)有技術(shù)中基于事件模擬進(jìn)行用戶界面測試中很容易漏測的問題，本發(fā) 明提供了一種基于事件模擬的用戶界面測試方法，具體技術(shù)方案包括以下步驟步驟1 接收測試用例，所述測試用例包含需要測試的事件的類型說明以及事件 發(fā)生的控件的類型說明；步驟2 根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求；步驟3 判斷當(dāng)前事件的合理性及完整性，并根據(jù)合理性及完整性對當(dāng)前事件進(jìn) 行處理；步驟4 通過調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件；步驟5 記錄當(dāng)前事件的運行日志。根據(jù)本發(fā)明的一優(yōu)選實施例，所述步驟3包括判斷控件的可操作性。根據(jù)本發(fā)明的一優(yōu)選實施例，控件不可操作的情況包括控件被隱藏、控件被覆蓋 或控件被剪裁。根據(jù)本發(fā)明的一優(yōu)選實施例，所述方法在控件不可操作的情況下返回false值并 結(jié)束當(dāng)前事件模擬請求。根據(jù)本發(fā)明的一優(yōu)選實施例，在控件可操作的情況下所述步驟3還包括判斷當(dāng)前 事件是否可分解及判斷當(dāng)前事件與上一個創(chuàng)建的事件之間是否存在需要補(bǔ)充的事件。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件可分解的情況下，所述方法還包括對當(dāng) 前事件分解后得到的一系列事件逐一發(fā)出當(dāng)前事件模擬請求。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件與上一個創(chuàng)建的事件之間存在需要補(bǔ)充 的事件時，所述方法還包括對需要補(bǔ)充的事件發(fā)出當(dāng)前事件模擬請求。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件不可分解且與上一個創(chuàng)建的事件之間不 存在需要補(bǔ)充的事件時，所述步驟3還包括將當(dāng)前事件保存為上一個創(chuàng)建的事件。本發(fā)明還提供了一種基于事件模擬的用戶界面測試裝置，包括接收單元，用于接收測試用例，所述測試用例包含需要測試的事件的類型說明以 及事件發(fā)生的控件的類型說明；請求單元，用于根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求；判斷單元，用于判斷當(dāng)前事件的合理性及完整性，并根據(jù)合理性及完整性對當(dāng)前 事件進(jìn)行處理；創(chuàng)建單元，用于通過調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件；記錄單元，用于記錄當(dāng)前事件的運行日志。根據(jù)本發(fā)明的一優(yōu)選實施例，判斷單元進(jìn)一步包括控件狀態(tài)判斷單元，用于判斷 控件的可操作性。根據(jù)本發(fā)明的一優(yōu)選實施例，控件不可操作的情況包括控件被隱藏、控件被覆蓋 或控件被剪裁。根據(jù)本發(fā)明的一優(yōu)選實施例，所述裝置在控件不可操作的情況下返回false值并 結(jié)束當(dāng)前事件模擬請求。根據(jù)本發(fā)明的一優(yōu)選實施例，在控件可操作的情況下判斷單元進(jìn)一步包括事件分 解判斷單元，用于判斷當(dāng)前事件是否可分解，及事件補(bǔ)充判斷單元，用于判斷當(dāng)前事件與上一個創(chuàng)建的事件之間是否存在需要補(bǔ)充的事件。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件可分解的情況下，事件分解判斷單元還 用于對當(dāng)前事件分解后得到的一系列事件逐一調(diào)用請求單元。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件與上一個創(chuàng)建的事件之間存在需要補(bǔ)充 的事件時，事件補(bǔ)充判斷單元還用于對需要補(bǔ)充的事件調(diào)用請求單元。根據(jù)本發(fā)明的一優(yōu)選實施例，在當(dāng)前事件不可分解且與上一個創(chuàng)建的事件之間不 存在需要補(bǔ)充的事件時，判斷單元還包括事件保存單元，用于將當(dāng)前事件保存為上一個創(chuàng) 建的事件。由以上技術(shù)方案可以看出，應(yīng)用本發(fā)明的基于事件模擬的用戶界面測試方法和裝 置，在用戶界面測試中可以很好地應(yīng)對用戶界面布局改變的情況，并且由于考慮了事件之 間的聯(lián)動性，在每次事件模擬請求中，都會考慮控件、事件之間的邏輯關(guān)系，自動產(chǎn)生符合 請求模擬的事件的邏輯關(guān)系的測試行為，可以很好地避免漏測的情況出現(xiàn)。

圖1為現(xiàn)有技術(shù)中基于事件模擬的用戶界面測試方法流程示意圖；圖2為本發(fā)明中基于事件模擬的用戶界面測試方法總流程示意圖；圖3為本發(fā)明中基于事件模擬的用戶界面測試方法實施例流程示意圖；圖4為本發(fā)明中基于事件模擬的用戶界面測試裝置總體結(jié)構(gòu)示意框圖；圖5為本發(fā)明中基于事件模擬的用戶界面測試裝置實施例結(jié)構(gòu)示意框圖。
具體實施方式為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖和具體實施例對 本發(fā)明進(jìn)行詳細(xì)描述。請參考圖2，圖2是本發(fā)明實施例中基于事件模擬的用戶界面測試方法總流程示 意圖。該方法主要包括以下步驟步驟101 接收測試用例，測試用例包含有事件類型說明和事件發(fā)生的控件類型 說明，即說明在什么控件上請求模擬什么事件，如果該事件需要傳遞參數(shù)，則請求中還包含 該事件的參數(shù)說明。測試用例是由測試人員編寫好的，其目的是為了通過這些測試用例的運行觀察系 統(tǒng)的響應(yīng)，從而發(fā)現(xiàn)用戶界面是否有錯誤發(fā)生。步驟102 根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求。測試用例描述了需要測試的事 件以及觸發(fā)這些事件的控件，因此步驟102中會根據(jù)步驟101中的測試用例發(fā)出當(dāng)前事件 的模擬請求。步驟103 判斷當(dāng)前事件合理性與完整性，并根據(jù)當(dāng)前事件的合理性與完整性對 當(dāng)前事件進(jìn)行相應(yīng)的處理。所謂的當(dāng)前事件的合理性，指的是當(dāng)前事件的發(fā)生是符合測試 邏輯的，即在當(dāng)前的用戶界面下，事件的確是可以發(fā)生的。所謂當(dāng)前事件的完整性，是指由 于當(dāng)前事件本身的性質(zhì)決定了當(dāng)前事件的發(fā)生跟其他事件有關(guān)或當(dāng)前事件的發(fā)生與上一 個事件有關(guān)。步驟104 通過調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件。這是真實地產(chǎn)生了一個經(jīng)步驟103處理后的當(dāng)前事件，即真正的測試行為。所謂上層工作環(huán)境，就是測試行為所處的 環(huán)境，例如在WEB用戶界面測試中，調(diào)用上層工作環(huán)境接口即調(diào)用瀏覽器接口。步驟105 記錄當(dāng)前事件運行日志。事件運行的日志中記錄了事件發(fā)生時的系統(tǒng) 運行狀況，通過事件運行日志，測試人員就可以發(fā)現(xiàn)用戶界面中可能存在的缺陷。下面通過具體的實施例對上述方法進(jìn)行詳細(xì)描述請一并參考圖2及圖3，圖3為本發(fā)明提供的基于事件模擬的用戶界面測試方法實 施例流程示意圖。步驟1011 接收測試用例，測試用例包含有事件類型說明和事件發(fā)生的控件類型 說明，即說明在什么控件上請求模擬什么事件，如果該事件需要傳遞參數(shù)，則請求中還包含 該事件的參數(shù)說明。步驟1021 發(fā)出當(dāng)前事件模擬請求。根據(jù)測試用例或者系統(tǒng)運行過程中的需要發(fā) 出事件模擬請求，請求中包含有需要測試的事件以及觸發(fā)這些事件的控件說明。步驟1031 判斷控件是否可操作，是則執(zhí)行步驟1032，否則返回false值并終止該 次事件模擬請求，執(zhí)行步驟1051。控件狀態(tài)是否可操作是指控件是否可見，控件不可見有可能是因為用戶界面布局 調(diào)整以后，該控件被隱藏或被別的控件覆蓋或被剪裁?？丶浑[藏有可能是在用戶界面變 化之后，業(yè)務(wù)邏輯使得該控件不在UI (用戶界面)上出現(xiàn)了?？丶桓采w有可能是在用戶界 面變化后，某個控件被另一個控件擋住，例如某個按鈕(button)上疊加了另外一個按鈕， 這時在下面的那個按鈕就是不可見的。控件被剪裁，是指在CSS中的剪裁樣式，使得控件部 分區(qū)域不可見。假設(shè)要測試不可操作的控件被單擊時的反應(yīng)，直接在該控件上模擬產(chǎn)生一 個click事件，有可能出現(xiàn)該控件上的click事件并不出錯的現(xiàn)象，從而導(dǎo)致我們無法發(fā)現(xiàn) 應(yīng)該發(fā)現(xiàn)的UI錯誤。實際上當(dāng)控件不可操作時是不可能被點擊的，不應(yīng)該模擬該事件的產(chǎn) 生，而是應(yīng)該直接返回false值。事實上，當(dāng)控件不可操作情況發(fā)生，正說明有可能發(fā)生了 用戶界面(UI)錯誤，如一個按鈕不該覆蓋在另一個按鈕上。步驟1032 判斷當(dāng)前事件是否可以分解，是則將當(dāng)前事件分解為一系列事件并針 對分解后的一系列事件發(fā)出當(dāng)前事件模擬請求，否則執(zhí)行步驟1033。事件可分解指的是某個瀏覽器事件的發(fā)生，是由一系列事件組合發(fā)生后觸發(fā)的， 例如雙擊(doubleclick)事件，它是由鼠標(biāo)按下(mousedown)事件、鼠標(biāo)彈起(mouseup)事 件、單擊(click)事件、鼠標(biāo)按下事件、鼠標(biāo)彈起事件依次順序發(fā)生后才觸發(fā)的。如果僅測 試doubleclick事件而沒有測試在doubleclick事件發(fā)生前必然發(fā)生的一系列事件，那么 有可能在實際使用中，用戶按得快不報錯，用戶按得慢就出錯的現(xiàn)象。這是因為在按得慢的 情況下，瀏覽器有可能認(rèn)為發(fā)生了兩次單擊事件，而單擊事件是有錯誤產(chǎn)生的，但是卻由于 沒有測試而無法得知這個錯誤，這顯然是我們不希望看到的。因此在本發(fā)明中，將對事件是 否可分解進(jìn)行判斷，在某個事件的發(fā)生可以分解為一系列事件組合發(fā)生時，將對這一系列 事件分別發(fā)出事件模擬請求。步驟1033 判斷當(dāng)前事件與上一個創(chuàng)建的事件之間是否存在需要補(bǔ)充的事件，是 則補(bǔ)充當(dāng)前事件與上一個創(chuàng)建的事件間缺少的事件并針對缺少的事件發(fā)出當(dāng)前事件模擬 請求，否則執(zhí)行步驟1034。當(dāng)前事件與上一事件之間存在需要補(bǔ)充的事件，指的是當(dāng)前事件與上一個創(chuàng)建的事件之間存在著邏輯上的聯(lián)系，在這兩者依次發(fā)生的時候，一定必須在其間發(fā)生其他事件， 否則這兩個事件不可能連續(xù)發(fā)生。例如當(dāng)前請求的是在控件B上產(chǎn)生mousedown事件，如果 之前創(chuàng)建的事件為控件A上的mousedown事件，那么很顯然，不可能連續(xù)發(fā)生兩次mousedown 事件，因此針對這種情況，在本發(fā)明中，將先在控件A上補(bǔ)充一個mouseup事件模擬請求。步驟1033中在判斷當(dāng)前事件與上一事件之間是否存在需要補(bǔ)充的事件時，需要 從上一事件存儲裝置中讀取上一事件的信息，包括上一事件的類型以及事件發(fā)生的對象。步驟1034 保存當(dāng)前事件為上一個創(chuàng)建的事件。即更新上一事件存儲裝置中的上 一事件信息，將上一事件變量值改為當(dāng)前請求的模擬事件。步驟1041 調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件。所謂上層工作環(huán)境，就是測試 行為所處的環(huán)境，例如在WEB用戶界面測試中，調(diào)用上層工作環(huán)境接口即調(diào)用瀏覽器接口。步驟1051 記錄事件運行日志。事件運行的日志中記錄了事件發(fā)生時的系統(tǒng)運行 狀況，通過事件運行日志，測試人員就可以發(fā)現(xiàn)用戶界面中可能存在的缺陷。在本發(fā)明中，步驟1031是對事件的合理性進(jìn)行判斷，即針對控件的狀態(tài)，判斷請 求的當(dāng)前事件是否合理，在合理的情況下繼續(xù)請求，不合理的情況下直接終止請求。步驟1032與步驟1033分別對事件完整性的不同方面進(jìn)行判斷，根據(jù)判斷結(jié)果， 自動將應(yīng)該測試的事件補(bǔ)充完整，值得注意的是，本實施例并不限定步驟1032和步驟1033 的執(zhí)行順序，可以按照本實施例說明先執(zhí)行步驟1032再執(zhí)行步驟1033，也可以先執(zhí)行步驟 1033再執(zhí)行步驟1032。請參考圖4，圖4為基于事件模擬的用戶界面測試裝置總體結(jié)構(gòu)示意框圖。該裝 置主要包括以下單元接收單元201、請求單元202、判斷單元203、創(chuàng)建單元204、記錄單元 205。其中接收單元201，用于接收測試用例。測試用例包含有事件類型說明和事件發(fā)生的控 件類型說明，即說明在什么控件上請求模擬什么事件，如果該事件需要傳遞參數(shù)，則請求中 還包含該事件的參數(shù)說明。測試用例是由測試人員編寫好的，其目的是為了通過這些測試用例的運行觀察系 統(tǒng)的響應(yīng)，從而發(fā)現(xiàn)用戶界面是否有錯誤發(fā)生。請求單元202，用于根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求。測試用例描述了需要測 試的事件以及觸發(fā)這些事件的控件，因此請求單元202中會根據(jù)接收單元201接收到的測 試用例發(fā)出當(dāng)前事件的模擬請求。判斷單元203，用于判斷當(dāng)前事件合理性與完整性，并根據(jù)當(dāng)前事件的合理性與完 整性對當(dāng)前事件進(jìn)行相應(yīng)的處理。所謂的當(dāng)前事件的合理性，指的是當(dāng)前事件的發(fā)生是符 合測試邏輯的，即在當(dāng)前的用戶界面下，事件的確是可以發(fā)生的。所謂當(dāng)前事件的完整性， 是指由于當(dāng)前事件本身的性質(zhì)決定了當(dāng)前事件的發(fā)生跟其他事件有關(guān)或當(dāng)前事件的發(fā)生 與上一個事件有關(guān)。創(chuàng)建單元204，用于通過調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件。這是真實地產(chǎn)生了 一個經(jīng)判斷單元處理后的當(dāng)前事件，即真正的測試行為。所謂上層工作環(huán)境，就是測試行為 所處的環(huán)境，例如在WEB用戶界面測試中，調(diào)用上層工作環(huán)境接口即調(diào)用瀏覽器接口。記錄單元205，用于記錄當(dāng)前事件運行日志。事件運行的日志中記錄了事件發(fā)生時 的系統(tǒng)運行狀況，通過事件運行日志，測試人員就可以發(fā)現(xiàn)用戶界面中可能存在的缺陷。
下面通過具體的實施例對上述裝置進(jìn)行詳細(xì)描述請一并參考圖4及圖5，圖5為本發(fā)明提供的基于事件模擬的用戶界面測試裝置實 施例結(jié)構(gòu)示意框圖。接收單元2011，用于接收測試用例，測試用例包含有事件類型說明和事件發(fā)生的 控件類型說明，即說明在什么控件上請求模擬什么事件，如果該事件需要傳遞參數(shù)，則請求 中還包含該事件的參數(shù)說明。請求單元2021，用于發(fā)出當(dāng)前事件模擬請求。請求單元根據(jù)測試用例或者系統(tǒng)運 行過程中的需要發(fā)出事件模擬請求，請求中包含有需要測試的事件以及觸發(fā)這些事件的控 件說明?？丶顟B(tài)判斷單元2031，用于判斷控件是否可操作，在控件可操作的情況下，繼續(xù) 當(dāng)前請求，否則返回false值并終止該次事件模擬請求?？丶顟B(tài)是否可操作是指控件是否可見，控件不可見有可能是因為用戶界面布局 調(diào)整以后，該控件被隱藏或被別的控件覆蓋或被剪裁。控件被隱藏有可能是在用戶界面變 化之后，業(yè)務(wù)邏輯使得該控件不在UI (用戶界面)上出現(xiàn)了?？丶桓采w有可能是在用戶界 面變化后，某個控件被另一個控件擋住，例如某個按鈕(button)上疊加了另外一個按鈕， 這時在下面的那個按鈕就是不可見的?？丶患舨?，是指在CSS中的剪裁樣式，使得控件部 分區(qū)域不可見。假設(shè)要測試不可操作的控件被單擊時的反應(yīng)，直接在該控件上模擬產(chǎn)生一 個click事件，有可能出現(xiàn)該控件上的click事件并不出錯的現(xiàn)象，從而導(dǎo)致我們無法發(fā)現(xiàn) 應(yīng)該發(fā)現(xiàn)的UI錯誤。實際上當(dāng)控件不可操作時是不可能被點擊的，不應(yīng)該模擬該事件的產(chǎn) 生，而是應(yīng)該直接返回false值。事實上，當(dāng)控件不可操作情況發(fā)生，正說明有可能發(fā)生了 用戶界面(UI)錯誤，如一個按鈕不該覆蓋在另一個按鈕上。事件分解判斷單元2032，用于判斷當(dāng)前事件是否可以分解，是則將當(dāng)前事件分解 為一系列事件并針對分解后的一系列事件調(diào)用請求單元，否則繼續(xù)當(dāng)前請求。事件可分解指的是某個瀏覽器事件的發(fā)生，是由一系列事件組合發(fā)生后觸發(fā)的， 例如雙擊(doubleclick)事件，它是由鼠標(biāo)按下(mousedown)事件、鼠標(biāo)彈起(mouseup)事 件、單擊(click)事件、鼠標(biāo)按下事件、鼠標(biāo)彈起事件依次順序發(fā)生后才觸發(fā)的。如果僅測 試doubleclick事件而沒有測試在doubleclick事件發(fā)生前必然發(fā)生的一系列事件，那么 有可能在實際使用中，用戶按得快不報錯，用戶按得慢就出錯的現(xiàn)象。這是因為在按得慢的 情況下，瀏覽器有可能認(rèn)為發(fā)生了兩次單擊事件，而單擊事件是有錯誤產(chǎn)生的，但是卻由于 沒有測試而無法得知這個錯誤，這顯然是我們不希望看到的。因此在本發(fā)明中，將對事件是 否可分解進(jìn)行判斷，在某個事件的發(fā)生可以分解為一系列事件組合發(fā)生時，將對這一系列 事件分別發(fā)出事件模擬請求。事件補(bǔ)充判斷單元2033，用于判斷當(dāng)前事件與上一個創(chuàng)建的事件之間是否存在需 要補(bǔ)充的事件，是則補(bǔ)充當(dāng)前事件與上一個創(chuàng)建的事件間缺少的事件并針對缺少的事件調(diào) 用請求單元，否則繼續(xù)當(dāng)前請求。當(dāng)前事件與上一事件之間存在需要補(bǔ)充的事件，指的是當(dāng)前事件與上一個創(chuàng)建 的事件之間存在著邏輯上的聯(lián)系，在這兩者依次發(fā)生的時候，一定必須在其間發(fā)生其他事 件，否則這兩個事件不可能連續(xù)發(fā)生。例如當(dāng)前請求的是在控件B上產(chǎn)生mousedown事 件，如果之前創(chuàng)建的事件為控件A上的mousedown事件，那么很顯然，不可能連續(xù)發(fā)生兩次mousedown事件，因此針對這種情況，在本發(fā)明中，將先在控件A上補(bǔ)充一個mouseup事件模 擬請求。事件補(bǔ)充判斷單元在判斷當(dāng)前事件與上一事件之間是否存在需要補(bǔ)充的事件時， 需要從上一事件存儲裝置中讀取上一事件的信息，包括上一事件的類型以及事件發(fā)生的對象。事件保存單元2034，用于保存當(dāng)前事件為上一個創(chuàng)建的事件。即更新上一事件存 儲裝置中的上一事件信息，將上一事件變量值改為當(dāng)前請求的模擬事件。創(chuàng)建單元2041，用于調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件。所謂上層工作環(huán)境，就 是測試行為所處的環(huán)境，例如在WEB用戶界面測試中，調(diào)用上層工作環(huán)境接口即調(diào)用瀏覽 器接口。記錄單元2051，用于記錄事件運行日志。事件運行的日志中記錄了事件發(fā)生時的 系統(tǒng)運行狀況，通過事件運行日志，測試人員就可以發(fā)現(xiàn)用戶界面中可能存在的缺陷。在本發(fā)明中，控件狀態(tài)判斷單元是對事件的合理性進(jìn)行判斷，即針對控件的狀態(tài)， 判斷請求的當(dāng)前事件是否合理，在合理的情況下繼續(xù)請求，不合理的情況下直接終止請求。事件分解判斷單元與事件補(bǔ)充判斷單元分別對事件完整性的不同方面進(jìn)行判斷， 根據(jù)判斷結(jié)果，自動將應(yīng)該測試的事件補(bǔ)充完整。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精 神和原則之內(nèi)，所做的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明保護(hù)的范圍之內(nèi)。
權(quán)利要求
1.一種基于事件模擬的用戶界面測試方法，其特征在于，所述方法包括步驟a.接收測試用例，所述測試用例包含需要測試的事件的類型說明以及所述事件發(fā)生的 控件的類型說明；b.根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求；c.判斷所述當(dāng)前事件的合理性及完整性，并根據(jù)所述合理性及完整性對所述當(dāng)前事件 進(jìn)行處理；d.通過調(diào)用上層工作環(huán)境接口創(chuàng)建所述當(dāng)前事件；e.記錄所述當(dāng)前事件的運行日志。
2.根據(jù)權(quán)利要求1所述的基于事件模擬的用戶界面測試方法，其特征在于，所述步驟c 包括判斷所述控件的可操作性。
3.根據(jù)權(quán)利要求2所述的基于事件模擬的用戶界面測試方法，其特征在于，所述控件 不可操作的情況包括所述控件被隱藏、所述控件被覆蓋或所述控件被剪裁。
4.根據(jù)權(quán)利要求2所述的基于事件模擬的用戶界面測試方法，其特征在于，所述方法 在所述控件不可操作的情況下返回false值并結(jié)束所述當(dāng)前事件模擬請求。
5.根據(jù)權(quán)利要求2所述的基于事件模擬的用戶界面測試方法，其特征在于，在所述控 件可操作的情況下所述步驟c還包括判斷所述當(dāng)前事件是否可分解及判斷所述當(dāng)前事件 與上一個創(chuàng)建的事件之間是否存在需要補(bǔ)充的事件。
6.根據(jù)權(quán)利要求5所述的基于事件模擬的用戶界面測試方法，其特征在于，在所述當(dāng) 前事件可分解的情況下，所述方法還包括對所述當(dāng)前事件分解后得到的一系列事件逐一發(fā) 出當(dāng)前事件模擬請求。
7.根據(jù)權(quán)利要求5所述的基于事件模擬的用戶界面測試方法，其特征在于，在所述當(dāng) 前事件與上一個創(chuàng)建的事件之間存在需要補(bǔ)充的事件時，所述方法還包括對所述需要補(bǔ)充 的事件發(fā)出當(dāng)前事件模擬請求。
8.根據(jù)權(quán)利要求6所述的基于事件模擬的用戶界面測試方法，其特征在于，在所述當(dāng) 前事件不可分解且與上一個創(chuàng)建的事件之間不存在需要補(bǔ)充的事件時，所述步驟c還包括 將所述當(dāng)前事件保存為上一個創(chuàng)建的事件。
9.一種基于事件模擬的用戶界面測試裝置，其特征在于，所述裝置包括接收單元，用于接收測試用例，所述測試用例包含需要測試的事件的類型說明以及所 述事件發(fā)生的控件的類型說明；請求單元，用于根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求；判斷單元，用于判斷所述當(dāng)前事件的合理性及完整性，并根據(jù)所述合理性及完整性對 所述當(dāng)前事件進(jìn)行處理；創(chuàng)建單元，用于通過調(diào)用上層工作環(huán)境接口創(chuàng)建所述當(dāng)前事件；記錄單元，用于記錄所述當(dāng)前事件的運行日志。
10.根據(jù)權(quán)利要求9所述的基于事件模擬的用戶界面測試裝置，其特征在于，所述判斷 單元進(jìn)一步包括控件狀態(tài)判斷單元，用于判斷所述控件的可操作性。
11.根據(jù)權(quán)利要求10所述的基于事件模擬的用戶界面測試裝置，其特征在于，所述控 件不可操作的情況包括所述控件被隱藏、所述控件被覆蓋或所述控件被剪裁。
12.根據(jù)權(quán)利要求10所述的基于事件模擬的用戶界面測試裝置，其特征在于，所述裝置在所述控件不可操作的情況下返回false值并結(jié)束所述當(dāng)前事件模擬請求。
13.根據(jù)權(quán)利要求10所述的基于事件模擬的用戶界面測試裝置，其特征在于，在所述 控件可操作的情況下所述判斷單元進(jìn)一步包括事件分解判斷單元，用于判斷所述當(dāng)前事件 是否可分解，及事件補(bǔ)充判斷單元，用于判斷所述當(dāng)前事件與上一個創(chuàng)建的事件之間是否 存在需要補(bǔ)充的事件。
14.根據(jù)權(quán)利要求13所述的基于事件模擬的用戶界面測試裝置，其特征在于，在所述 當(dāng)前事件可分解的情況下，所述事件分解判斷單元還用于對所述當(dāng)前事件分解后得到的一 系列事件逐一調(diào)用請求單元。
15.根據(jù)權(quán)利要求13所述的基于事件模擬的用戶界面測試裝置，其特征在于，在所述 當(dāng)前事件與上一個創(chuàng)建的事件之間存在需要補(bǔ)充的事件時，所述事件補(bǔ)充判斷單元還用于 對所述需要補(bǔ)充的事件調(diào)用請求單元。
16.根據(jù)權(quán)利要求13所述的基于事件模擬的用戶界面測試裝置，其特征在于，在所述 當(dāng)前事件不可分解且與上一個創(chuàng)建的事件之間不存在需要補(bǔ)充的事件時，所述判斷單元還 包括事件保存單元，用于將所述當(dāng)前事件保存為上一個創(chuàng)建的事件。
全文摘要
本發(fā)明提供了一種基于事件模擬的用戶界面測試方法，包括接收測試用例，所述測試用例包含需要測試的事件的類型說明以及事件發(fā)生的控件的類型說明；根據(jù)測試用例發(fā)出當(dāng)前事件模擬請求；判斷當(dāng)前事件的合理性及完整性，并根據(jù)合理性及完整性對當(dāng)前事件進(jìn)行處理；通過調(diào)用上層工作環(huán)境接口創(chuàng)建當(dāng)前事件；記錄當(dāng)前事件的運行日志。依據(jù)本發(fā)明，在用戶界面測試中可以很好地應(yīng)對用戶界面布局改變的情況，并且由于考慮了事件之間的聯(lián)動性，在每次事件模擬請求中，都會考慮控件、事件之間的邏輯關(guān)系，自動產(chǎn)生符合請求模擬的事件的邏輯關(guān)系的測試行為，可以很好地避免漏測的情況出現(xiàn)。
文檔編號G06F11/36GK102073590SQ20111000478
公開日2011年5月25日 申請日期2011年1月11日 優(yōu)先權(quán)日2011年1月11日
發(fā)明者歐陽先偉 申請人:百度在線網(wǎng)絡(luò)技術(shù)(北京)有限公司