激情欧美日韩一区二区,浪货撅高贱屁股求主人调教视频,精品无码成人片一区二区98,国产高清av在线播放,色翁荡息又大又硬又粗视频

UI自動(dòng)化測試驅動(dòng)的軟件開(kāi)發(fā)方法研究

時(shí)間:2024-09-02 10:16:28 計算機軟件畢業(yè)論文 我要投稿
  • 相關(guān)推薦

UI自動(dòng)化測試驅動(dòng)的軟件開(kāi)發(fā)方法研究

  軟件在開(kāi)發(fā)的過(guò)程中有很多方式,不同的軟件開(kāi)發(fā)也需要不同的技術(shù)。下面是小編搜集整理的測試驅動(dòng)開(kāi)發(fā)研究的論文范文,供大家閱讀借鑒。

UI自動(dòng)化測試驅動(dòng)的軟件開(kāi)發(fā)方法研究

  【摘 要】在軟件測試中,UI測試是保證軟件質(zhì)量、提高軟件可靠性不可或缺的一部分,而基于單元的測試驅動(dòng)開(kāi)發(fā)對UI的關(guān)注度不夠,本文探討了適用于測試驅動(dòng)開(kāi)發(fā)的UI自動(dòng)化測試框架需要的性質(zhì)以及框架結構,并用開(kāi)源框架KIF展示了UI自動(dòng)化測試在測試驅動(dòng)開(kāi)發(fā)中的應用。

  【關(guān)鍵詞】軟件測試,UI測試,測試驅動(dòng),極限編程

  引言

  測試驅動(dòng)開(kāi)發(fā)是一種新的軟件開(kāi)發(fā)方式,它遵守測試先行的原則,既簡(jiǎn)化了代碼,又提高了軟件的質(zhì)量,已經(jīng)成功的運用到各種項目的開(kāi)發(fā),F今的軟件由于越來(lái)越注重軟件的用戶(hù)體驗,對UI的測試越來(lái)越重要,而現在的測試驅動(dòng)開(kāi)發(fā)以測試代碼單元設計正確性為主的單元測試為主要驅動(dòng),極少考慮用戶(hù)與UI的操作對程序的影響,所以,研究UI測試在測試驅動(dòng)開(kāi)發(fā)中的應用有重要意義。

  1、測試驅動(dòng)開(kāi)發(fā)

  測試驅動(dòng)開(kāi)發(fā)(Test- Driven Development), 簡(jiǎn)稱(chēng)TDD, 由 Kent Beck提出的一種軟件開(kāi)發(fā)方式。測試驅動(dòng)開(kāi)發(fā)以測試作為開(kāi)發(fā)過(guò)程的中心, 它要求在編寫(xiě)任何產(chǎn)品代碼之前, 首先編寫(xiě)用于定義產(chǎn)品代碼行為的測試, 而編寫(xiě)的產(chǎn)品代碼又要以使測試通過(guò)為目標。測試驅動(dòng)開(kāi)發(fā)要求測試可以完全自動(dòng)化的運行, 在對代碼進(jìn)行重構前后必須運行測試。

  1.1 傳統測試方法存在的問(wèn)題

  1)傳統的功能性測試存在著(zhù)漏洞和冗余, 而且同時(shí)不能被發(fā)現。功能性測試使測試人員離代碼過(guò)遠;

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

  3)如果測試編寫(xiě)人員編寫(xiě)測試時(shí)所依賴(lài)的是文檔而不是代碼時(shí), 當文檔和代碼存在任何不一致的地方就會(huì )造成問(wèn)題;

  4)測試不是自動(dòng)運行的, 它們極有可能不會(huì )被頻繁、經(jīng)常性地運行, 或每次都以相同的方式來(lái)運行。

  1.2 測試驅動(dòng)開(kāi)發(fā)的優(yōu)點(diǎn)

  1)從軟件開(kāi)發(fā)的初始階段, TDD 就強迫開(kāi)發(fā)人員以測試的角度與用戶(hù)的觀(guān)點(diǎn)對軟件進(jìn)行審視,因而更能夠對軟件有全面的認識和把握。

  2)由于可以保證編寫(xiě)測試和編寫(xiě)代碼的是相同的程序員, 降低了理解代碼所花費的成本。

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

  4)讓程序員能夠更大程度地控制代碼的正確度, 相當于提供了兩道的代碼審核手段, 在軟件成品的質(zhì)量上提供了一定的保障。

  1.3 測試驅動(dòng)開(kāi)發(fā)步驟

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

  2)運行所有測試,新增加的測試無(wú)法通過(guò);

  3)重構代碼,做盡量少的改動(dòng)讓測試通過(guò);

  4)運行所有測試,保證所有測試都能通過(guò);

  5)重構代碼,消除重復設計;

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

  2、UI測試

  在移動(dòng)互聯(lián)網(wǎng)時(shí)代 ,用戶(hù)體驗是軟件的重中之重,為了保證用戶(hù)體驗的完美必須對軟件UI進(jìn)行嚴格測試,ui 測試主要分為可用性測試和功能性測試兩方面。對于可用性測試,是用來(lái)測試軟件的用戶(hù)界面是否符合用戶(hù)的使用習慣和使用心理,是對用戶(hù)體驗的歸納和總結。用戶(hù)體驗的好壞取決于用戶(hù)界面是否簡(jiǎn)單、直觀(guān)和實(shí)用,良好的用戶(hù)界面可以大大減少可用性測試的成本。對于功能性測試,通過(guò)外部UI的內容和展示用來(lái)測試軟件的內部邏輯正確性。

  2.1 自動(dòng)化測試

  根據測試是否需要引入人工干預,軟件測試可以分為手工測試和自動(dòng)化測試兩大類(lèi)。手工測試是指采用手動(dòng)的方式輸入軟件測試的數據,然后觀(guān)察測試的結果,并對測試結果進(jìn)行分析。相對于自動(dòng)化測試,手工測試是一種原始的測試方法。自動(dòng)化測試是指通過(guò)編寫(xiě)測試腳本,對軟件進(jìn)行測試,整個(gè)過(guò)程不需要人工進(jìn)行干預。手工測試能夠根據軟件測試的進(jìn)度,及時(shí)的調整測試的策略,改變軟件測試的方法。手工測試能夠細致的觀(guān)察到軟件運行和輸出的結果,當需要對測試結果進(jìn)行主觀(guān)判斷時(shí),手工測試具有明顯的優(yōu)點(diǎn)。但是,手工測試也存在著(zhù)自身的不足。相對于自動(dòng)化測試,手工測試的效率較低,不確定的因素較多。當軟件測試需要測試大量的數據時(shí),手工測試的局限性較為明顯。完成采用手工測試對軟件進(jìn)行測試,無(wú)法滿(mǎn)足現代化的軟件測試需求。因此,采用手動(dòng)測試加自動(dòng)化測試相結合的方式對軟件進(jìn)行測試,可以有效的提高測試效率,縮短測試時(shí)間,提高測試的準確性。

  自動(dòng)化測試相對于手工測試,主要有以下幾點(diǎn)優(yōu)勢:

  1)提高測試效率

  手工測試是一個(gè)勞動(dòng)密集型的工作,并且容易出錯。引入自動(dòng)化測試能夠用有效、可重復的自動(dòng)測試環(huán)境代替繁瑣的手工測試活動(dòng),而且能夠在更少的時(shí)間內完成更多的測試工作,從而提高了測試工程師的工作效率。

  2)降低對軟件新版本進(jìn)行回歸測試的開(kāi)銷(xiāo)

  對于現代軟件的迭代增量開(kāi)發(fā),每一個(gè)新版本大部分功能和界面都和上一個(gè)版本相似或完全相同,這時(shí)要對新版本再次進(jìn)行已有的測試,這部分工作多為重復工作,特別適合使用自動(dòng)化測試來(lái)完成,從而減小回歸測試的開(kāi)銷(xiāo)。

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

  對于一些非功能型方面的測試,如壓力測試、并發(fā)測試、大數據量測試、崩潰性測試等,這些測試用手工測試是很難,甚至是不可能完成的。但自動(dòng)化測試則能方便的執行這些測試,比如并發(fā)測試,使用自動(dòng)化測試工具就可以模擬來(lái)自多方的并發(fā)操作了。

  4)具有一致性和重復性

  每次自動(dòng)化測試運行的腳本是相同的,所以可以進(jìn)行重復的測試,使得每次的測試具有一致性,手工測試則很難做到這點(diǎn)。

  5)更好地利用資源

  將繁瑣的測試任務(wù)自動(dòng)化,可以使測試人員解脫出來(lái),將精力更多地到測試案例的設計和必要的手工測試當中。并且理想的自動(dòng)化測試能夠按計劃完全自動(dòng)地運行,使得完全可以利用周末和晚上的時(shí)間執行自動(dòng)化測試,每日構建技術(shù)日漸普遍。   6)降低風(fēng)險,增加軟件信任度

  自動(dòng)化測試能通過(guò)較少的開(kāi)銷(xiāo)獲得更徹底的測試效果,從而更好地提高了軟件產(chǎn)品地質(zhì)量。

  2.2 自動(dòng)化測試方法與工具

  現在存在著(zhù)各種各樣的UI自動(dòng)化測試框架,例如SilkTest和UIAutomation,這類(lèi)軟件和軟件的開(kāi)發(fā)環(huán)境相對獨立,一般有自己專(zhuān)用的腳本語(yǔ)言和測試用例描述方法,適合于傳統開(kāi)發(fā)模式下的先開(kāi)發(fā)后測試,不符合測試驅動(dòng)開(kāi)發(fā)的原則。本文用開(kāi)源框架KIF展示了UI自動(dòng)化測試在測試驅動(dòng)開(kāi)發(fā)中的應用。

  3、適用于測試驅動(dòng)開(kāi)發(fā)的UI自動(dòng)化測試框架

  3.1 測試驅動(dòng)開(kāi)發(fā)對UI測試需求根據測試驅動(dòng)的開(kāi)發(fā)過(guò)程和UI自動(dòng)化測試的技術(shù)的介紹,可以總結出對于適用于測試驅動(dòng)的UI測試的要求:

  1)可視化:普通的單元測試對UI部分功能進(jìn)行測試,但是只能證明功能的邏輯正確性,卻無(wú)法看到該功能對UI的影響,通常需要再編譯一遍程序,手動(dòng)來(lái)測試UI的正確性。所以,UI測試應用在測試驅動(dòng)開(kāi)發(fā)時(shí),要求其必須在測試過(guò)程中可視化。

  2)自動(dòng)化:即能夠模擬用戶(hù)對界面的操作,如點(diǎn)擊、滑動(dòng)、捏合等手勢,這些操作可通過(guò)各平臺的accessibility功能實(shí)現。

  語(yǔ)言一致性:由于測試驅動(dòng)開(kāi)發(fā)遵循“測試先行”的策略,對于測試腳本的通用性要求不高,所以,采用與軟件開(kāi)發(fā)一致的語(yǔ)言既能減少開(kāi)發(fā)人員的學(xué)習成本,又能充分利用各平臺的accessibility功能。

  3)集成擴展性:由于現今的開(kāi)發(fā)環(huán)境大都緊密集成成熟的單元測試框架,在該框架的基礎上集成對UI控件的訪(fǎng)問(wèn)、操作功能,不僅能滿(mǎn)足UI測試的需求,還能保證測試框架功能的完備性。同時(shí),由于UI操作方式的多種多樣,要求框架必須具備靈活性,要有一定的擴展能力。

  3.2 測試框架結構

  UI自動(dòng)化測試框架的基礎為成熟的單元測試框架上,并對單元測試進(jìn)行擴展,另外添加了模擬用戶(hù)操作的模擬、以及對用戶(hù)操作對象UI控件的擴展(圖1)。

  3.3 框架工作流程

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

  1)加載并解析測試用例(假如存在單獨的測試用例描述文件);

  2)按照測試腳本所描述的操作操作方法對界面進(jìn)行輸入、點(diǎn)擊、滑動(dòng)等操作;

  3)通過(guò)界面控件的屬性與期望結果對比,判斷是否執行成功;

  4)輸出測試結果。

  3.4 UI自動(dòng)化測試驅動(dòng)程序開(kāi)發(fā)步驟

  根據測試驅動(dòng)的開(kāi)發(fā)步驟,聯(lián)合以UI為測試核心的需求,總結出基于UI自動(dòng)化測試的測試驅動(dòng)開(kāi)發(fā)步驟:

  1)根據界面的功能以及用戶(hù)對界面的操作快速添加相應的測試用例;

  2)運行所有測試,新增加的測試無(wú)法通過(guò);

  3)修改用戶(hù)界面以及對界面的交互代碼,做盡量少的改動(dòng)讓測試通過(guò);

  4)運行所有測試,保證所有測試都能通過(guò);

  5)重構代碼,消除重復設計;

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

  4、測試驅動(dòng)開(kāi)發(fā)實(shí)例

  本文通過(guò)一個(gè)簡(jiǎn)單的IOS系統的登錄界面的實(shí)例來(lái)展示UI測試驅動(dòng)開(kāi)發(fā)方法。

  4.1 UI界面描述

  4.1.1 界面功能描述

  登錄界面有兩個(gè)文本框,一個(gè)登錄按鈕。文本框分別用來(lái)輸入用戶(hù)名和密碼,登錄按鈕用來(lái)確認并提交登錄信息。

  4.1.2 用戶(hù)操作要求

  1)用戶(hù)名字符數在3-6之間;

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

  3)用戶(hù)輸入超過(guò)上限則只顯示前8位;

  4)用戶(hù)輸入低于下限則讓文本框獲得焦點(diǎn)并顯示鍵盤(pán),等待用戶(hù)繼續輸入;

  5)點(diǎn)擊確認按鈕,若用戶(hù)信息不符合要求則讓讓不符合要求的文本框獲取焦點(diǎn),若符合要求則提交驗證;

  6)點(diǎn)擊界面空白處取消焦點(diǎn)。

  4.2 UI自動(dòng)化測試驅動(dòng)的開(kāi)發(fā)過(guò)程實(shí)例

  在界面上添加用戶(hù)控件兩個(gè)文本框和相應的說(shuō)明標簽,一個(gè)按鈕,并設置其訪(fǎng)問(wèn)屬性,此為程序的初始狀態(tài)。

  4.2.1 用戶(hù)名輸入測試

  1)根據用戶(hù)操作要求,書(shū)寫(xiě)用戶(hù)輸入上限的測試代碼如下:

  代碼解釋?zhuān)斎離ukaitian超出了上限,所以文本框中應該顯示期望值xukait。

  2)運行測試,此時(shí)測試失敗,查看測試日志,提示與預期結果不符:

  3)修改界面控制器的代碼,給文本框添加輸入變化控制代碼如下:

  4)再次運行測試,此時(shí)測試成功:

  5)重復上述步驟,分別對用戶(hù)名輸入下限測試以及其他限制條件進(jìn)行測試開(kāi)發(fā)。

  5、結語(yǔ)

  測試驅動(dòng)開(kāi)發(fā)在各項目上的成功運用激勵了越來(lái)越多的開(kāi)發(fā)者采用者這種開(kāi)發(fā)方式,與此同時(shí),用戶(hù)對用戶(hù)體驗的追求也促使開(kāi)發(fā)者將越來(lái)越多的注意力放在UI界面上,本文針對這兩種現象,提出了UI測試在測試驅動(dòng)開(kāi)發(fā)中的應用,重點(diǎn)闡述了適用于測試驅動(dòng)開(kāi)發(fā)的UI自動(dòng)化測試框架應具有的性質(zhì)和其架構,并以IOS平臺的KIF為例展示了其實(shí)踐應用。在本文提出的架構中,對測試用例的描述解析考慮較少,這是下一步工作的重點(diǎn)。

  【參考文獻】

  [1]蔡長(cháng)霞.劉建平 基于敏捷測試的自動(dòng)化技術(shù)分析與實(shí)踐[J].工業(yè)控制計算機,2011,24(10).

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

  [3]科恩.Scrum 敏捷軟件開(kāi)發(fā)[M].廖靖斌,呂梁岳,陳爭云,等,譯.北京:清華大學(xué)出版社,2012.

  [4]Kniberg,Henrik.Scrum and XP from the Trenches,Lulu[Z].com,2007.

  [5]楊怡君,黃大慶.Android 手機自動(dòng)化性能測試工具的研究與開(kāi)發(fā)[J].計算機應用,2012,32(2):554-556.

  [6]Freeman Harries. Software testing.IEEE.Vol5[Z].Sep, 2002:48-50.

【UI自動(dòng)化測試驅動(dòng)的軟件開(kāi)發(fā)方法研究】相關(guān)文章:

IPM驅動(dòng)和保護電路的研究03-20

軟件性能測試研究03-28

鈮酸鋰光開(kāi)關(guān)的驅動(dòng)電路的研究03-07

關(guān)于面向軟件測試過(guò)程的知識管理方法的研究與實(shí)現03-15

軟件開(kāi)發(fā)團隊的知識創(chuàng )新研究03-19

鉭電解電容器噪聲測試方法及應用研究11-22

選區激光燒結瞬態(tài)溫度場(chǎng)數值模擬與測試方法研究03-07

基于顧客情感和諧的情感營(yíng)銷(xiāo)驅動(dòng)模式研究03-22

手機自動(dòng)化測試系統設計淺析03-07

給排水專(zhuān)業(yè)CAD軟件開(kāi)發(fā)方法探討03-18

激情欧美日韩一区二区,浪货撅高贱屁股求主人调教视频,精品无码成人片一区二区98,国产高清av在线播放,色翁荡息又大又硬又粗视频