UI自動化測試驅動的軟體開發方法研究

才智咖 人氣:8.49K

軟體在開發的過程中有很多方式,不同的軟體開發也需要不同的技術。下面是小編蒐集整理的測試驅動開發研究的論文範文,供大家閱讀借鑑。

UI自動化測試驅動的軟體開發方法研究

【摘 要】在軟體測試中,UI測試是保證軟體質量、提高軟體可靠性不可或缺的一部分,而基於單元的測試驅動開發對UI的關注度不夠,本文探討了適用於測試驅動開發的UI自動化測試框架需要的性質以及框架結構,並用開源框架KIF展示了UI自動化測試在測試驅動開發中的應用。

【關鍵詞】軟體測試,UI測試,測試驅動,極限程式設計

引言

測試驅動開發是一種新的軟體開發方式,它遵守測試先行的原則,既簡化了程式碼,又提高了軟體的質量,已經成功的運用到各種專案的開發。現今的軟體由於越來越注重軟體的使用者體驗,對UI的測試越來越重要,而現在的測試驅動開發以測試程式碼單元設計正確性為主的單元測試為主要驅動,極少考慮使用者與UI的操作對程式的影響,所以,研究UI測試在測試驅動開發中的應用有重要意義。

1、測試驅動開發

測試驅動開發(Test- Driven Development), 簡稱TDD, 由 Kent Beck提出的一種軟體開發方式。測試驅動開發以測試作為開發過程的中心, 它要求在編寫任何產品程式碼之前, 首先編寫用於定義產品程式碼行為的測試, 而編寫的產品程式碼又要以使測試通過為目標。測試驅動開發要求測試可以完全自動化的執行, 在對程式碼進行重構前後必須執行測試。

1.1 傳統測試方法存在的問題

1)傳統的功能性測試存在著漏洞和冗餘, 而且同時不能被發現。功能性測試使測試人員離程式碼過遠;

2)傳統的結構性測試將程式碼採用有向圖表示和程式路徑公式化, 掩蓋了程式碼中的重要資訊, 這就在路徑分析的方向上走得太遠;

3)如果測試編寫人員編寫測試時所依賴的是文件而不是程式碼時, 當文件和程式碼存在任何不一致的地方就會造成問題;

4)測試不是自動執行的, 它們極有可能不會被頻繁、經常性地執行, 或每次都以相同的方式來執行。

1.2 測試驅動開發的優點

1)從軟體開發的初始階段, TDD 就強迫開發人員以測試的角度與使用者的觀點對軟體進行審視,因而更能夠對軟體有全面的認識和把握。

2)由於可以保證編寫測試和編寫程式碼的是相同的程式設計師, 降低了理解程式碼所花費的成本。

3)減輕了測試的工作量。無論是否進行設計工作, 測試工作都是不可避免的, 先進行單元測試, 可以減少後續的測試工作量。

4)讓程式設計師能夠更大程度地控制程式碼的正確度, 相當於提供了兩道的`程式碼稽核手段, 在軟體成品的質量上提供了一定的保障。

1.3 測試驅動開發步驟

1)根據軟體設計需求快速增加一個測試用例;

2)執行所有測試,新增加的測試無法通過;

3)重構程式碼,做盡量少的改動讓測試通過;

4)執行所有測試,保證所有測試都能通過;

5)重構程式碼,消除重複設計;

6)回到1)直到寫完系統所有的功能測試。

 2、UI測試

在移動網際網路時代 ,使用者體驗是軟體的重中之重,為了保證使用者體驗的完美必須對軟體UI進行嚴格測試,ui 測試主要分為可用性測試和功能性測試兩方面。對於可用性測試,是用來測試軟體的使用者介面是否符合使用者的使用習慣和使用心理,是對使用者體驗的歸納和總結。使用者體驗的好壞取決於使用者介面是否簡單、直觀和實用,良好的使用者介面可以大大減少可用性測試的成本。對於功能性測試,通過外部UI的內容和展示用來測試軟體的內部邏輯正確性。

2.1 自動化測試

根據測試是否需要引入人工干預,軟體測試可以分為手工測試和自動化測試兩大類。手工測試是指採用手動的方式輸入軟體測試的資料,然後觀察測試的結果,並對測試結果進行分析。相對於自動化測試,手工測試是一種原始的測試方法。自動化測試是指通過編寫測試指令碼,對軟體進行測試,整個過程不需要人工進行干預。手工測試能夠根據軟體測試的進度,及時的調整測試的策略,改變軟體測試的方法。手工測試能夠細緻的觀察到軟體執行和輸出的結果,當需要對測試結果進行主觀判斷時,手工測試具有明顯的優點。但是,手工測試也存在著自身的不足。相對於自動化測試,手工測試的效率較低,不確定的因素較多。當軟體測試需要測試大量的資料時,手工測試的侷限性較為明顯。完成採用手工測試對軟體進行測試,無法滿足現代化的軟體測試需求。因此,採用手動測試加自動化測試相結合的方式對軟體進行測試,可以有效的提高測試效率,縮短測試時間,提高測試的準確性。

自動化測試相對於手工測試,主要有以下幾點優勢:

1)提高測試效率

手工測試是一個勞動密集型的工作,並且容易出錯。引入自動化測試能夠用有效、可重複的自動測試環境代替繁瑣的手工測試活動,而且能夠在更少的時間內完成更多的測試工作,從而提高了測試工程師的工作效率。

2)降低對軟體新版本進行迴歸測試的開銷

對於現代軟體的迭代增量開發,每一個新版本大部分功能和介面都和上一個版本相似或完全相同,這時要對新版本再次進行已有的測試,這部分工作多為重複工作,特別適合使用自動化測試來完成,從而減小回歸測試的開銷。

3)完成手工測試不能或難以完成的測試

對於一些非功能型方面的測試,如壓力測試、併發測試、大資料量測試、崩潰性測試等,這些測試用手工測試是很難,甚至是不可能完成的。但自動化測試則能方便的執行這些測試,比如併發測試,使用自動化測試工具就可以模擬來自多方的併發操作了。

4)具有一致性和重複性

每次自動化測試執行的指令碼是相同的,所以可以進行重複的測試,使得每次的測試具有一致性,手工測試則很難做到這點。

5)更好地利用資源

將繁瑣的測試任務自動化,可以使測試人員解脫出來,將精力更多地到測試案例的設計和必要的手工測試當中。並且理想的自動化測試能夠按計劃完全自動地執行,使得完全可以利用週末和晚上的時間執行自動化測試,每日構建技術日漸普遍。   6)降低風險,增加軟體信任度

自動化測試能通過較少的開銷獲得更徹底的測試效果,從而更好地提高了軟體產品地質量。

2.2 自動化測試方法與工具

現在存在著各種各樣的UI自動化測試框架,例如SilkTest和UIAutomation,這類軟體和軟體的開發環境相對獨立,一般有自己專用的指令碼語言和測試用例描述方法,適合於傳統開發模式下的先開發後測試,不符合測試驅動開發的原則。本文用開源框架KIF展示了UI自動化測試在測試驅動開發中的應用。

3、適用於測試驅動開發的UI自動化測試框架

3.1 測試驅動開發對UI測試需求根據測試驅動的開發過程和UI自動化測試的技術的介紹,可以總結出對於適用於測試驅動的UI測試的要求:

1)視覺化:普通的單元測試對UI部分功能進行測試,但是隻能證明功能的邏輯正確性,卻無法看到該功能對UI的影響,通常需要再編譯一遍程式,手動來測試UI的正確性。所以,UI測試應用在測試驅動開發時,要求其必須在測試過程中視覺化。

2)自動化:即能夠模擬使用者對介面的操作,如點選、滑動、捏合等手勢,這些操作可通過各平臺的accessibility功能實現。

語言一致性:由於測試驅動開發遵循“測試先行”的策略,對於測試指令碼的通用性要求不高,所以,採用與軟體開發一致的語言既能減少開發人員的學習成本,又能充分利用各平臺的accessibility功能。

3)整合擴充套件性:由於現今的開發環境大都緊密整合成熟的單元測試框架,在該框架的基礎上整合對UI控制元件的訪問、操作功能,不僅能滿足UI測試的需求,還能保證測試框架功能的完備性。同時,由於UI操作方式的多種多樣,要求框架必須具備靈活性,要有一定的擴充套件能力。

3.2 測試框架結構

UI自動化測試框架的基礎為成熟的單元測試框架上,並對單元測試進行擴充套件,另外添加了模擬使用者操作的模擬、以及對使用者操作物件UI控制元件的擴充套件(圖1)。

3.3 框架工作流程

根據UI測試框架架構圖,可以清晰的看到其工作流程:

1)載入並解析測試用例(假如存在單獨的測試用例描述檔案);

2)按照測試指令碼所描述的操作操作方法對介面進行輸入、點選、滑動等操作;

3)通過介面控制元件的屬性與期望結果對比,判斷是否執行成功;

4)輸出測試結果。

3.4 UI自動化測試驅動程式開發步驟

根據測試驅動的開發步驟,聯合以UI為測試核心的需求,總結出基於UI自動化測試的測試驅動開發步驟:

1)根據介面的功能以及使用者對介面的操作快速新增相應的測試用例;

2)執行所有測試,新增加的測試無法通過;

3)修改使用者介面以及對介面的互動程式碼,做盡量少的改動讓測試通過;

4)執行所有測試,保證所有測試都能通過;

5)重構程式碼,消除重複設計;

6)回到1)直到寫完系統所有的功能測試。

 4、測試驅動開發例項

本文通過一個簡單的IOS系統的登入介面的例項來展示UI測試驅動開發方法。

4.1 UI介面描述

4.1.1 介面功能描述

登入介面有兩個文字框,一個登入按鈕。文字框分別用來輸入使用者名稱和密碼,登入按鈕用來確認並提交登入資訊。

4.1.2 使用者操作要求

1)使用者名稱字元數在3-6之間;

2)密碼字元數在6-8之間;

3)使用者輸入超過上限則只顯示前8位;

4)使用者輸入低於下限則讓文字框獲得焦點並顯示鍵盤,等待使用者繼續輸入;

5)點選確認按鈕,若使用者資訊不符合要求則讓讓不符合要求的文字框獲取焦點,若符合要求則提交驗證;

6)點選介面空白處取消焦點。

4.2 UI自動化測試驅動的開發過程例項

在介面上新增使用者控制元件兩個文字框和相應的說明標籤,一個按鈕,並設定其訪問屬性,此為程式的初始狀態。

4.2.1 使用者名稱輸入測試

1)根據使用者操作要求,書寫使用者輸入上限的測試程式碼如下:

程式碼解釋,輸入xukaitian超出了上限,所以文字框中應該顯示期望值xukait。

2)執行測試,此時測試失敗,檢視測試日誌,提示與預期結果不符:

3)修改介面控制器的程式碼,給文字框新增輸入變化控制程式碼如下:

4)再次執行測試,此時測試成功:

5)重複上述步驟,分別對使用者名稱輸入下限測試以及其他限制條件進行測試開發。

5、結語

測試驅動開發在各專案上的成功運用激勵了越來越多的開發者採用者這種開發方式,與此同時,使用者對使用者體驗的追求也促使開發者將越來越多的注意力放在UI介面上,本文針對這兩種現象,提出了UI測試在測試驅動開發中的應用,重點闡述了適用於測試驅動開發的UI自動化測試框架應具有的性質和其架構,並以IOS平臺的KIF為例展示了其實踐應用。在本文提出的架構中,對測試用例的描述解析考慮較少,這是下一步工作的重點。

 【參考文獻】

[1]蔡長霞.劉建平 基於敏捷測試的自動化技術分析與實踐[J].工業控制計算機,2011,24(10).

[2]何浩,程春玲.基於SilkTesst和XML的通用高效的使用者介面測試方法[J].計算機應用,2013,33(1):258-261.

[3]科恩m 敏捷軟體開發[M].廖靖斌,呂梁嶽,陳爭雲,等,譯.北京:清華大學出版社,2012.

[4]Kniberg,m and XP from the Trenches,Lulu[Z],2007.

[5]楊怡君,黃大慶oid 手機自動化效能測試工具的研究與開發[J].計算機應用,2012,32(2):554-556.

[6]Freeman Harries. Software 5[Z], 2002:48-50.