饒建農(nóng)

摘要：當(dāng)今的軟件系統(tǒng)通常以圖形用戶界面（GUI）為特征，但是對于圖形界面的測試大多數(shù)都是手工操作完成，因此存在成本高，浪費(fèi)時間等缺點(diǎn)。在GUI軟件自動化測試的基礎(chǔ)上，通過程序代碼，將輸出結(jié)果和輸入進(jìn)行對比，分析自動化測試的結(jié)果，研究出一種不利用GUI完成以GUI為基礎(chǔ)的軟件的測試方法。實(shí)驗(yàn)結(jié)果證明，不利用GUI功能來測試GUI軟件的嘗試得到了部分成功。

關(guān)鍵詞：圖形用戶界面;軟件測試;測試方法;軟件工程環(huán)境;程序邏輯

中圖分類號：TP311? ? ? ? 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2019）17-0078-04

開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

Abstract： Today's software systems are usually characterized by a graphical user interface （GUI）， but for most of the graphical interface testing manual to complete， so there is a high cost and waste of time and other shortcomings. On the basis of the automated testing of GUI software， by the code， compare the output and input， analyze the results of automated testing and come up with a non-use GUI to complete the GUI-based software testing methods.The experimental results show，do not use the GUI functionality to test the GUI software attempt has been partially successful.

Key words： Graphical User Interface（GUI）;software testing;test methods;Software Engineering Environment（SEE）;program logic

1 引言

當(dāng)今的軟件系統(tǒng)通常以圖形式用戶界面（GUI）為特征。那些幫助程序員利用圖形界面產(chǎn)生應(yīng)用系統(tǒng)的工具，已經(jīng)戲劇化地改進(jìn)了程序員的效率，但是也增加了測試者的壓力。這種軟件必須在每一次使用之前得到徹底地測試。

當(dāng)今的圖形界面測試大多數(shù)都是手工操作完成，這種方法成本較高且浪費(fèi)時間。因此，需要有完全自動化的測試程序。如果使用自動化測試程序，將極大地減少測試所需的時間和人力。

本文著重研究如何解決一個具有GUI功能的應(yīng)用程序，可以在不使用GUI的環(huán)境下被測試和引導(dǎo);研究自動復(fù)原測試如何執(zhí)行，使測試結(jié)果在應(yīng)用程序功能發(fā)生變化的情況下不受影響或產(chǎn)生最小的影響。

不利用GUI功能來測試GUI的嘗試得到了部分成功。這種自動化測試依賴于被測試產(chǎn)品的結(jié)構(gòu)。課題的測試目標(biāo)在某種程度上被結(jié)構(gòu)化，這可能使測試方法變得困難和費(fèi)時。

2 相關(guān)理論

2.1 測試的概念

在Glen Myers的經(jīng)典著作《The Art of Software Testing》中，給出了測試的定義：“程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”。另外，Glen Myers還給出了與測試相關(guān)的三個重要觀點(diǎn)，那就是：測試是為了證明程序有錯，而不是證明程序無錯誤;一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤;一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。當(dāng)然測試用例在軟件開發(fā)之前不能執(zhí)行，但是可以在需求規(guī)格的基礎(chǔ)上進(jìn)行設(shè)計(jì)。

測試的質(zhì)量可以描述為下列幾個屬性：效力、模范性和成本考慮。

2.2 驗(yàn)證和確認(rèn)

驗(yàn)證和確認(rèn)能確保軟件的規(guī)格和顧客的滿足程度。驗(yàn)證可以確保系統(tǒng)實(shí)現(xiàn)所有的要求，確保每一個功能都準(zhǔn)確地實(shí)現(xiàn)。也就是說，驗(yàn)證可以確保開發(fā)者按照規(guī)格開發(fā)正確的產(chǎn)品，同時審核執(zhí)行質(zhì)量。

驗(yàn)證和確認(rèn)可以分成兩種技術(shù)，即：靜態(tài)技術(shù)和動態(tài)技術(shù)。

2.2.1 測試過程

大型軟件系統(tǒng)的測試過程包含幾個階段，這些階段分為：單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試和復(fù)原測試。復(fù)原測試是測試中的必要部分，但是當(dāng)進(jìn)行手工操作的時候，就變得非常地反復(fù)和沉悶。這種測試越來越重要，需要通過發(fā)展周期來完成，如圖1所示。

所有這些流程都應(yīng)該盡可能經(jīng)常運(yùn)行。圖中的箭頭表明了測試的正常順序，當(dāng)箭頭返回到先前的框架中時，表明先前的測試可能被重復(fù)，也就是復(fù)原測試。

復(fù)原測試也可能導(dǎo)致編輯現(xiàn)有測試用例或者產(chǎn)生新的用例。

2.2.2 測試技術(shù)

測試設(shè)計(jì)方法分為兩類：白盒測試和黑盒測試。

白盒測試：這種測試技術(shù)基于程序代碼、程序描述或者技術(shù)設(shè)計(jì)的基礎(chǔ)上，對系統(tǒng)內(nèi)在結(jié)構(gòu)的認(rèn)知起著重要的作用。

黑盒測試：這種測試技術(shù)基于功能規(guī)格和質(zhì)量要求的基礎(chǔ)上。在黑盒技術(shù)中，系統(tǒng)被認(rèn)為是可以實(shí)際應(yīng)用的。

2.2.3 測試成本

如同任何事物一樣，軟件也有一個孕育、誕生、成長、成熟、衰亡的生存過程。一般稱其為計(jì)算機(jī)軟件的生存期。根據(jù)這一思想，把上述基本的過程活動進(jìn)一步展開，可以得到軟件生存期的六個步驟，即制定計(jì)劃、需求分析、設(shè)計(jì)、程序編碼、測試及運(yùn)行維護(hù)。

每一階段的相關(guān)成本，可以歸結(jié)為如表1和表2所述：

測試、發(fā)現(xiàn)和修改程序中的錯誤可以在軟件生存期的任何階段進(jìn)行，占總開發(fā)成本的40%到80%。然而，發(fā)現(xiàn)和修改錯誤的成本隨著開發(fā)的推進(jìn)顯著增加。在代碼寫完之前，更改需求文件比代碼寫完之后進(jìn)行修改要花費(fèi)得少，因?yàn)榇a必須重寫。程序員在發(fā)現(xiàn)錯誤后進(jìn)行維護(hù)成本是比較低的，因?yàn)樗麄儾恍枰蚱渌私忉專@就不會產(chǎn)生溝通費(fèi)用。在運(yùn)行程序之前修改錯誤所花費(fèi)的成本，要比發(fā)出新磁盤，給一個技術(shù)員，一個客戶后修改所花費(fèi)的成本低得多。

2.3 軟件工程環(huán)境

軟件工程環(huán)境（SEE）是一組硬件和軟件工具，它可以以一種集成的方式運(yùn)行，為整個軟件程序從最初的規(guī)劃一直到測試和運(yùn)行提供支持。

軟件工程環(huán)境運(yùn)行的平臺被稱為客戶系統(tǒng)。一般情況下，用軟件工程環(huán)境開發(fā)的軟件將會在相同的平臺中運(yùn)行，但是在許多情況下，它可能傳送到一些目標(biāo)系統(tǒng)，而這些目標(biāo)系統(tǒng)有一個完全不同的結(jié)構(gòu)和運(yùn)行系統(tǒng)。

3 不利用圖形界面，來實(shí)現(xiàn)以圖形界面為基礎(chǔ)的軟件的測試的自動化

3.1 介紹

通過使用GUI對以GUI為基礎(chǔ)的軟件進(jìn)行自動化測試時存在兩個問題：軟件改變時，都會需要大量地維護(hù)性工作;軟件運(yùn)行時，如果存在繪圖區(qū)，繪圖區(qū)尺寸就會改變，這使得繪圖區(qū)的測試變得困難。

為了避免上面提到的問題，本節(jié)著重于尋找不使用GUI來實(shí)現(xiàn)GUI軟件測試自動化的可能性，也就是依靠程序代碼。本節(jié)也要定義測試目標(biāo)必須完成的要求，發(fā)現(xiàn)形成測試自動化的可能技術(shù)。

為了完成測試，使用Telelogic公司開發(fā)的Telelogic Tau（由UML Suite， SDL Suite， TTCN Suite， SCADE 和Logiscpoe組成）作為測試工具。

3.2 Telelogic庫的概況

Telelogic庫分為幾個目錄和子庫。庫是Telelogic Tau的一個完整部分，庫被分成四個不同的層次。庫框架體現(xiàn)了結(jié)構(gòu)和公共代碼庫，代碼庫以特定的方式允許維護(hù)和開發(fā)軟件的某些方面。

為了了解庫界面是如何互動的，需要一個例子。這個例子顯示菜單選擇時事件的過程。通過選擇菜單，在應(yīng)用系統(tǒng)庫中的功能被激活。這一功能喚起框架子庫中的菜單選擇功能。

3.3 測試目標(biāo)的選擇

為了完成測試，測試目標(biāo)應(yīng)當(dāng)有一個簡單的結(jié)構(gòu)與少數(shù)的菜單，因?yàn)檫@能使獲得和追蹤可能存在的漏洞變得更簡單。

在Telelogic Tau的編輯器中，有兩種軟件能實(shí)現(xiàn)這一目的：MSCE（Message Sequence Chart Editor）和HMSCE（High-level Message Sequence Chart Editor）。

本文選擇HMSCE作為測試目標(biāo)。然后給出具體的描述，調(diào)查HMSCE中菜單、對話框和繪圖區(qū)的功能。

3.3.1 菜單

在Windows環(huán)境下有兩種菜單，分別是下拉式菜單和彈出式菜單。

下拉式菜單：這類菜單從應(yīng)用程序窗口的菜單欄中激活，允許用戶選擇將要執(zhí)行的命令。

彈出式菜單：也稱為快捷菜單或上下式菜單，當(dāng)點(diǎn)擊鼠標(biāo)右鍵時出現(xiàn)。鼠標(biāo)單擊的區(qū)域不同，彈出的菜單內(nèi)容一般也不同。

3.3.2 對話框

對話框通常用來顯示信息或者提示用戶輸入繼續(xù)執(zhí)行應(yīng)用程序所需要的數(shù)據(jù)。分為模態(tài)對話框和非模態(tài)對話框。模態(tài)對話框要求在繼續(xù)執(zhí)行應(yīng)用程序的其他操作之前，必須先被關(guān)閉，或?qū)λ奶崾咀龀鲰憫?yīng)。非模態(tài)對話框允許在關(guān)閉對話框之前對應(yīng)用程序的其他部分做出響應(yīng)或操作，即當(dāng)對話框正在顯示時，可以繼續(xù)操作當(dāng)前應(yīng)用程序的其他部分。

從測試的角度分類，對話框分為安裝/選項(xiàng)對話框和消息對話框。這些對話框可能是模態(tài)式的或者非模態(tài)式的。

安裝/選項(xiàng)對話框：這類對話框分成兩類。第一類選擇可能安裝的狀態(tài)和命令按鈕的數(shù)目。第二類幾乎同第一類相同，不同的是：按鈕被安裝后，不能改變現(xiàn)有按鈕的數(shù)目。

消息對話框：消息對話框被提前安裝，經(jīng)常會彈出來提醒用戶某些內(nèi)容被改變或者運(yùn)行錯誤。消息對話框通常僅有一個按鈕，而用戶不能有任何選擇，只是確認(rèn)消息的內(nèi)容。

有些消息對話框也有幾個按鈕，但是它們?nèi)匀皇枪潭▽υ捒?，主要提醒用戶某些?nèi)容被改變，用戶可以接受或者拒絕這種改變。

3.3.3 繪圖區(qū)

當(dāng)在繪圖區(qū)處理目標(biāo)時，了解某個功能被調(diào)用時對軟件的影響是非常重要的。一個好的測試用例，其目的在于實(shí)現(xiàn)繪圖區(qū)測試的自動化，使測試者把這些測試活動用于運(yùn)行自動化測試的輸入。

滿足這種需求需要測試用例覆蓋一些重要的活動，例如增加、刪除、產(chǎn)生和復(fù)制目標(biāo)等。

3.4 案例研究

3.4.1 介紹

本文研究的目的是：調(diào)查GUI軟件的自動化測試如何提高測試質(zhì)量;是什么原因使現(xiàn)有產(chǎn)品的自動化測試變得困難;如何在將來的產(chǎn)品測試中克服這些困難。

通過測試案例的運(yùn)行，理解了自動化測試的過程，發(fā)現(xiàn)了造成困難的原因。

3.4.2 計(jì)劃

當(dāng)軟件測試開始之前，了解軟件存在問題和軟件的功能是非常重要的。因此第一階段就是去調(diào)查Telelogic庫的結(jié)構(gòu)和子庫之間的界面，如表3所示。

調(diào)查的目的是找出一個可以抓取所有信號的界面，利用這個界面，GUI和邏輯程序可以互相交流。

這些信號用于菜單、對話框和繪圖區(qū)的分別測試。

在Telelogic Tau的研究中，發(fā)現(xiàn)GUI和程序代碼是兩個相互交疊的單元，如圖2所示。因此，所需要的界面并不存在。

由于界面的缺乏，使得統(tǒng)一操作和掌控所有部件是不可能的。因此，菜單，對話框和繪圖區(qū)必須被分別測試。

3.4.3 執(zhí)行

為抓取信號，有許多工具可以使用。把Telelogic庫分成四個子庫的目的就是為了編寫宏和把宏放到包含程序代碼的應(yīng)用子庫中去，這對于所有類型的編輯器都是相同的。優(yōu)點(diǎn)是能夠測試和掌控任意編輯器，但是這種方法也比較費(fèi)時，因?yàn)椴粌H是程序代碼可能寫在Unix和Windows兩個運(yùn)行系統(tǒng)上，而且對于一個簡單的調(diào)用活動，必須改變子庫中的許多其他程序。

為了避免這種復(fù)雜性，框架子庫看起來同應(yīng)用子庫相比是一個更好的轉(zhuǎn)變。在此子庫中，有一個功能被稱為Win菜單選擇。用這一功能，能調(diào)用編輯子庫中所需編輯器的其他功能。從子庫中調(diào)用編輯需要現(xiàn)有程序代碼的大量改變。

在其他HMSC編輯中，子庫包含所有種類的編輯器。因?yàn)椴藛慰杀贿x為測試目標(biāo)。在此編輯器中，有一種被稱為菜單選擇的功能執(zhí)行菜單的選擇。在宏的幫助下，包括菜單選擇功能的HMSCPage等級被定義為Original HMSCPage等級，它繼承了來自于先前等級的所有功能。

測試執(zhí)行期間，多余的窗口將會被同時打開。因此，菜單和調(diào)試窗口兩者將會以兩種獨(dú)特的界面顯示。

3.4.4 結(jié)果

通過抓取/回放功能的輸入輸出文件之間的對比，清楚地顯示了菜單項(xiàng)的自動化測試是可行的，但是它并不是對現(xiàn)有產(chǎn)品的測試技術(shù)。盡管本論題的觀念是研究菜單，對話框和繪圖區(qū)域的測試，但是由于時間和軟件產(chǎn)品的缺乏，不容易實(shí)現(xiàn)對對話框和繪圖區(qū)域進(jìn)行測試。

4 結(jié)論

4.1 設(shè)計(jì)上的測試執(zhí)行

菜單項(xiàng)的測試可以通過宏抓取回叫信號來完成。對話框和繪圖區(qū)用同樣方法也是可以的，但是由于現(xiàn)有軟件產(chǎn)品的結(jié)構(gòu)，這種方法比較困難而且費(fèi)時。

從測試指向來看，有三種類型的對話框，也就是兩種安裝對話框和一種信息對話框。由于這些對話框缺少一個公共的界面，因此這三種對話框可能會被分別測試。這就意味著回叫信號不可能由一個簡單的宏抓取，會有大量的變化，而這種變化反過來會影響幾個文件。

進(jìn)行繪圖區(qū)的測試時，除對話框測試存在的問題外，還應(yīng)該考慮其他的問題：繪圖窗口的尺寸和抓取回叫信號的可用性。主要的問題是：每次軟件運(yùn)行時，或者打開窗口而其他窗口也打開的時候，窗口的尺寸都會改變。這可能導(dǎo)致抓取的回叫信號和當(dāng)前位置有所不同。因此對自動化測試來說，抓取的回叫信號不能看作是重播功能的輸入。

回叫信號的可用性意味著：在進(jìn)行調(diào)試時，抓取到的回叫信號能實(shí)現(xiàn)自動化測試，能夠直接地使用重播功能，或者為實(shí)現(xiàn)這一目的做好準(zhǔn)備。

一個普遍的問題就是平臺的依靠性。例如，對于一些對話框，其測試必須安裝在Unix和Windons雙重平臺之上。

另一個問題就是原有的測試數(shù)據(jù)的持久性。如果一個菜單在下個軟件中菜單項(xiàng)增加或者刪除，原來抓取的數(shù)據(jù)就是沒有用的了，因?yàn)樾碌牟藛尾煌谙惹败浖牟藛?。持久性問題可以通過保存所有菜單的功能來解決，也可以在最初運(yùn)行手工測試來解決。

很明顯的，這些測試工具需要很多時間，要由有經(jīng)驗(yàn)的測試者來安裝，要由有經(jīng)驗(yàn)地對系統(tǒng)有良好知識的測試者來運(yùn)行。

在Telelogic公司，在現(xiàn)有軟件中不借助GUI的使用去測試GUI軟件，那也是非常困難的，或者是不可能的。

4.2 建議和未來的研究

要想能夠測試以GUI為基礎(chǔ)的軟件而不利用GUI的話，第一步應(yīng)該是從程序邏輯中分離出GUI。這種分離應(yīng)該給出所需的界面，也就是公共界面。由于現(xiàn)有軟件的結(jié)構(gòu)，在應(yīng)用庫中生成這種界面是可能的。這種方法可以使菜單和一些對話框的測試更容易。

公共界面使得能抓取所有的數(shù)據(jù)（這些數(shù)據(jù)可以用作重放功能的輸入）。這種重放功能可以用手寫代碼實(shí)現(xiàn)，通過使用抓取數(shù)據(jù)激活應(yīng)用程序。正確的結(jié)果可以通過比較重放功能的輸入和輸出而得到。通過公共界面抓取的信號輸入到重放功能的繪圖區(qū)域時，需要當(dāng)前產(chǎn)品結(jié)構(gòu)上有巨大的改變。

另一種想法是在程序邏輯上寫更多的代碼和生成GUI的尺寸盡可能小，這種方法的目的是盡量減少基于GUI軟件的自動化測試的GUI的工作量。好處就是測試程序邏輯比GUI可能更容易一些。

參考文獻(xiàn)：

[1] Paul C. Jorgensen.Software Testing A Craftsmans Approach[M].北京：機(jī)械工業(yè)出版社，2005.

[2] 王謙.基于評價軟件測試的有效性問題研究[J].計(jì)算機(jī)光盤軟件與應(yīng)用，2012（4）.

[3] 于凌云.軟件測試的實(shí)踐研究[J].電腦知識與技術(shù)，2010（27）：7664-7666.

[4] 鐘百成，張言上.關(guān)于軟件測試技術(shù)的探討[J].數(shù)字技術(shù)與應(yīng)用，2012（2）：133-135.

【通聯(lián)編輯：代影】