第八章-軟件測試自動化ppt課件(全)_第1頁
第八章-軟件測試自動化ppt課件(全)_第2頁
第八章-軟件測試自動化ppt課件(全)_第3頁
第八章-軟件測試自動化ppt課件(全)_第4頁
第八章-軟件測試自動化ppt課件(全)_第5頁
已閱讀5頁,還剩95頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

1、第八章 軟件測試自動化第1頁/共100頁測試面臨的問題測試用例會越來越多,工作量越來越大,而且許多測試用例會被不斷地重復(fù)執(zhí)行。如果由手工來完成,不僅占用很多人力資源,而且工作重復(fù)單調(diào),會影響測試人員的積極性,降低測試工作人員的熱情 怎么辦?測試自動化第2頁/共100頁目錄8.1 自動化測試的作用與優(yōu)勢8.2 自動化測試的原理8.3 自動化工具的分類與選擇8.4 自動化測試的引入第3頁/共100頁8.1自動化測試的作用與優(yōu)勢什么是自動化測試?自動化測試(automated test)是相對手工測試(manual test)而存在的一個概念,由手工逐個地運行測試用例的操作過程被測試工具自動執(zhí)行的過

2、程所代替。第4頁/共100頁自動化測試的作用手工測試的不足: 手工測試執(zhí)行時間長,測試效率低。 由于手工測試的工作量很大,在測試人員不足或測試周期很短的情況下,難以達到測試的充分性要求。第5頁/共100頁當(dāng)修改了軟件之后,經(jīng)常難以及時完成有效的回歸測試。同時,回歸測試是典型的重復(fù)性測試工作,會使測試人員感到單調(diào)枯燥。當(dāng)測試過程包含大量測試用例和測試數(shù)據(jù)時,測試執(zhí)行和管理的細(xì)節(jié)會很繁瑣,容易出錯。第6頁/共100頁難以便捷和全面地對測試進程及其結(jié)果進行統(tǒng)計分析并生成規(guī)范性的測試報告。性能測試時無法模擬大規(guī)模軟件系統(tǒng)負(fù)載。難以完成系統(tǒng)可靠性測試,無法模擬驗證系統(tǒng)連續(xù)運行幾個月甚至幾年后是否仍然能夠

3、穩(wěn)定運行。第7頁/共100頁手工測試 發(fā)現(xiàn)缺陷率高 容易實施 創(chuàng)造性、靈活性 覆蓋率量化困難 重復(fù)測試效率低 不一致性、可靠性低 依賴人力資源 高效率(速度) 高復(fù)用性 覆蓋率容易度量 準(zhǔn)確、可靠 不知疲勞 激勵團隊士氣 機械、難以發(fā)現(xiàn)缺陷 一次性投入大自動測試手工測試 vs.自動測試第8頁/共100頁兩者相互補充在系統(tǒng)功能邏輯測試、驗收測試、適用性測試、涉及交互性測試時,多采用手工測試方法;單元測試、集成測試、系統(tǒng)負(fù)載或性能、可靠性測試等比較適合采用自動測試;對那種不穩(wěn)定、開發(fā)周期短或一次性的軟件等不適合自動測試;工具本身缺乏想象力和創(chuàng)造性,自動測試只能發(fā)現(xiàn)15%的缺陷,而手工測試可以發(fā)現(xiàn)8

4、5%的缺陷;第9頁/共100頁測試工具對軟件測試的影響 測試工具的廣泛使用大大提高了軟件測試的自動化程度。通過測試工具可以模擬手工測試的步驟,控制被測軟件的運行,自動完成測試用例執(zhí)行結(jié)果的判斷,實現(xiàn)半自動或全自動的測試過程。第10頁/共100頁 需要注意的是,自動化測試不可能完全替代手工測試,很多的測試過程還必須依靠手工測試完成。自動化測試和手工測試在實際工作中應(yīng)當(dāng)取長補短、綜合使用。此外,自動化測試并不只是單純使用測試工具,還包括應(yīng)用自動化測試的思想和方法,建立適應(yīng)自動化測試的策略與工作流程。第11頁/共100頁8.1.2 自動化測試的優(yōu)勢自動化的性能測試 性能測試需要模擬大量的負(fù)載,最常見

5、的是模擬成百上千的并發(fā)用戶來測試系統(tǒng)的性能瓶頸、驗證各種性能指標(biāo),離開測試工具是根本無法完成的。因此,類似性能測試這種需要模擬大量用戶和并發(fā)任務(wù)的測試活動非常適合采用自動化測試。第12頁/共100頁自動化的回歸測試 回歸測試是重復(fù)已執(zhí)行過的測試,避免修改程序?qū)υ姓9δ墚a(chǎn)生影響?;貧w測試用例是已經(jīng)完全設(shè)計好的,即使有些改動一般也不會太多,而且測試的預(yù)期結(jié)果也是完全可以確定的。第13頁/共100頁回歸測試中自動化與手工測試工作量對比第14頁/共100頁圖8-1 回歸測試中自動化與手工測試工作量對比自動化與手工測試工作量對比: 自動化測試在初次測試時因為要開發(fā)自動化測試用例,工作量會大于手工測試

6、。但是隨著回歸測試的增多,初期產(chǎn)生的工作量被均攤,總工作量明顯小于手工測試,并且回歸測試的次數(shù)越多效果越明顯。第15頁/共100頁自動化測試的其他一些優(yōu)勢可以規(guī)范整個測試流程,方便地進行軟件缺陷跟蹤和管理。測試的全面性明顯優(yōu)于手工測試。能更好地保證程序代碼、測試用例和相關(guān)文檔記錄的版本一致性。第16頁/共100頁提高功能測試基本操作和數(shù)據(jù)驗證的質(zhì)量和效率。便于捕捉偶然發(fā)生的軟件缺陷。能更好地利用人力資源。將繁瑣、單調(diào)和重復(fù)的工作交由自動化測試來做。第17頁/共100頁8.2 自動化測試的原理8.2.1 測試用例的錄制與回放 很多軟件或?qū)iT的軟件工具都提供了錄制特定軟件操作的功能,最常見的是Mi

7、crosoft Word中的宏。 圖8-2 Microsoft Word中錄制宏的窗口第18頁/共100頁適合錄制為宏的任務(wù): 對于Word中需要反復(fù)執(zhí)行的某些任務(wù),可以將其錄制為宏,通過運行錄制后的宏來自動執(zhí)行該任務(wù)。 例如,插入具有指定尺寸、邊框、行數(shù)和列數(shù)的表格,或者是將手工去除空格、文字查找與替換、格式修改等個性化排版操作錄制為一個宏,方便之后進行一次性操作。第19頁/共100頁例子:在Word中插入一個22的表格、選擇表格樣式、在每個表格中輸入一個數(shù)據(jù)”錄制為宏,其腳本代碼如下所示。第20頁/共100頁Sub 宏1()注釋ActiveDocument.Tables.Add Range

8、:=Selection.Range, NumRows:=2, NumColumns:= _ 2, DefaultTableBehavior:=wdWord9TableBehavior, AutoFitBehavior:= _ wdAutoFitFixed With Selection.Tables(1) If .Style 網(wǎng)格型 Then .Style = 網(wǎng)格型 End If .ApplyStyleHeadingRows = True .ApplyStyleLastRow = False .ApplyStyleFirstColumn = True .ApplyStyleLastColumn

9、 = False .ApplyStyleRowBands = True .ApplyStyleColumnBands = False 從上面Word宏的例子可知,通過工具可以將軟件操作和數(shù)據(jù)輸入錄制為相應(yīng)的腳本因此可以通過,運行腳本重復(fù)之前的所有操作。第21頁/共100頁End With Selection.Tables(1).Style = 淺色底紋 - 強調(diào)文字顏色 5 Selection.TypeText Text:=數(shù)據(jù)1 Selection.MoveRight Unit:=wdCell Selection.TypeText Text:=數(shù)據(jù)2 Selection.MoveRight

10、Unit:=wdCell Selection.TypeText Text:=數(shù)據(jù)3 Selection.MoveRight Unit:=wdCell Selection.TypeText Text:=數(shù)據(jù)4End Sub開源測試工具Katalon Recorder 安裝過程 在“ ”注冊用戶后下載自己需要的版本,也可以在谷歌應(yīng)用商店或者通過火狐瀏覽器插件下載和安裝Katalon IDE。安裝完成后,在火狐瀏覽器的右上角出現(xiàn)Katalon Recorder的快捷圖標(biāo)。第22頁/共100頁圖8-3 Katalon Recorder IDE的界面第23頁/共100頁使用Katalon Recorde

11、r IDE錄制一個簡單的自動化測試腳本。新建一個測試用例“Test Case Demo”,然后單擊“Record”按鈕開始錄制。在Firefox瀏覽器中輸入網(wǎng)址“”,在打開的頁面中選擇出現(xiàn)的文字“XXXX年XX月XX日 星期X ”,單擊鼠標(biāo)右鍵后從彈出的菜單中選“Katalon Recorder”“verifyText”這樣就增加了一個驗證點。第24頁/共100頁采用相同的方法,圖8-4為測試運行結(jié)果。第25頁/共100頁 測試腳本由一個“open”和兩個“verifyText”命令組成。 如圖8-4所示。第一個驗證點通過,相應(yīng)的命令變?yōu)榫G色;第二個驗證點失敗,命令窗口中的命令文字變?yōu)榧t色,測

12、試日志窗口中也以紅色文字提示“error did not match”。 結(jié)論:第二個驗證點的秒時間數(shù)字在不斷變化,與最初記錄的預(yù)期結(jié)果不同,因此驗證失敗,由此也說明測試工具可以自動發(fā)現(xiàn)非常微小的結(jié)果偏差。第26頁/共100頁 可以將測試用例導(dǎo)出為各種常用語言的腳本。單擊“Export”按鈕,在下拉框中選擇希望的腳本語言即可。這樣就節(jié)省了測試人員編寫復(fù)雜測試腳本的工作量,只需要在錄制好的腳本基礎(chǔ)上進行修改即可。如圖8-5測試腳本的輸出。第27頁/共100頁圖8-5 測試腳本的輸出第28頁/共100頁總結(jié) 自動化測試的一般過程是首先啟動被測軟件和相應(yīng)的測試工具,通過測試工具錄制軟件操作過程并且插

13、入驗證點,對錄制好的腳本進行必要的調(diào)試,然后保存腳本作為測試用例。執(zhí)行測試時,調(diào)用自動化測試腳本,通過腳本操縱被測軟件執(zhí)行,驗證測試結(jié)果,根據(jù)測試工具的執(zhí)行日志生成軟件缺陷報告。第29頁/共100頁8.2.2 代碼分析靜態(tài)分析工具FindBugs 靜態(tài)分析工具FindBugs可以檢查和分析Java代碼類或者Jar文件,在不實際運行程序的情況對Java源程序進行靜態(tài)測試。將程序代碼與定義的代碼規(guī)則或缺陷模式進行對比可以發(fā)現(xiàn)很多種軟件缺陷。第30頁/共100頁FindBugs常用的規(guī)則主要可以分為以下幾類。Correctness(正確性)。代碼可能在某些方面不正確。Bad practice(不良實

14、踐)。源程序明確違反規(guī)定的編碼規(guī)范。Performance(性能)??赡軐?dǎo)致軟件性能不佳的代碼。第31頁/共100頁Multithreaded correctness(多線程的正確性)。多線程編程時可能導(dǎo)致錯誤的代碼。Dodgy(不可靠)。具有潛在危險的代碼。 通過上述規(guī)則,F(xiàn)indBugs能夠幫助開發(fā)人員發(fā)現(xiàn)源程序中存在的代碼缺陷或隱患,并且提供了修改意見供開發(fā)人員參考,大大提高了Code Review的效率與質(zhì)量。第32頁/共100頁 圖8-6 Eclipse中FindBugs的規(guī)則配置頁面第33頁/共100頁對象識別功能測試工具需要和用戶界面打交道,就需要能操作、控制用戶界面上各種對象,

15、所以大部分功能測試工具是基于GUI對象識別技術(shù)來實現(xiàn)自動化測試的。對象的識別,就是獲得這個對象的類別、名稱、屬性的值。第34頁/共100頁1、類、對象、屬性和方法 打開網(wǎng)頁http:/www.newtours.后可以看到如圖8-7所示的頁面部分,圖中包含以下一些典型的GUI對象。第35頁/共100頁對于圖8-7所示對象的解釋 鏈接SIGN-ON、REGISTER、SUPPORT和CONTACT是LINK類的對象,對象SIGN-ON具有諸如“href”和“text”這樣的屬性,通過這些屬性用戶可以進入特定的網(wǎng)頁。第36頁/共100頁 “User Name”和“Password”是WebEdit編

16、輯框類的對象。對象“User Name”具有諸如“name”和“max-length”這樣的屬性,通過這些屬性可以在給定Web頁面中唯一識別該對象。對象“User Name”具有一個方法(method)集合,通過方法實現(xiàn)在編輯框中輸入文本。 基本上,你所看到的應(yīng)用程序的所有GUI元素都是特定類的對象。 第37頁/共100頁 UFT有如下一些默認(rèn)的“add-ins”,可以增加更多的擴展“add-ins”以支持不同類型的應(yīng)用程序。支持的應(yīng)用程序包括:ActiveXMobileUI AutomationVisual BasicWeb第38頁/共100頁圖8-8 UFT中的對象識別對話框第39頁/共1

17、00頁 UFT中的軟件單元“Object Spy”能夠具體識別一個特定對象的屬性、屬性的值和方法。 圖8-9是例子中“SIGN-ON”對象的屬性和操作,這里的操作(Operations)也就是對象的方法(Methods)。第40頁/共100頁圖8-9 通過Object Spy識別對象屬性與方法第41頁/共100頁2、對象庫對象庫在對象識別和功能測試中的作用圖8-10 測試設(shè)計與執(zhí)行流程中的對象庫第42頁/共100頁“測試設(shè)計”和“測試執(zhí)行”兩個階段上述兩種測試階段對象的含義如下。運行時對象(Run-time Objects)是被測軟件的實際對象,在執(zhí)行測試時與測試對象的屬性進行對比匹配。測試對

18、象(Test Objects)存儲在對象庫中,包含一系列的對象屬性。UFT通過學(xué)習(xí)GUI對象的屬性以及屬性值來產(chǎn)生測試對象。第43頁/共100頁對象庫的測試原理 運行腳本時,UFT會根據(jù)對象庫中測試對象的特征屬性描述來查找運行時對象,然后對比對象屬性。如果一致,進行后續(xù)操作;如果不一致,則提示對象無法識別。第44頁/共100頁圖8-11 UFT中對象庫的管理界面第45頁/共100頁3、UFT對象識別的完整過程(1)描述屬性(Description Properties) 在第一個階段,UFT組合使用強制(Mandatory)屬性和輔助(Assistive)屬性完成對象識別,上述兩種屬性的組合被

19、稱為已學(xué)習(xí)描述(Learned Description),有時也稱為描述屬性(Description Properties)或測試對象描述(Test Object Description)。第46頁/共100頁圖8-12 UFT對象識別過程第47頁/共100頁(2)可視關(guān)系標(biāo)識符(Visual Relation Identifiers,VRI) 在這一階段,UFT利用可視關(guān)系標(biāo)識符VRI完成對象識別,VRI定義了對象與其鄰居對象的相對位置。VRI是UFT中新增的對象識別機制。第48頁/共100頁如圖8-13(a)所示,一個Web頁面上有兩個“Submit”按鈕,因為不管以后這些按鈕出現(xiàn)在網(wǎng)頁的

20、什么位置,“OK”按鈕總是會出現(xiàn)在第一個“Submit”按鈕的左邊。所以,即使在以后的測試過程中,這些按鈕在網(wǎng)頁中的位置相反(如圖8-13(b)所示),UFT仍然能夠識別出第一個“Submit”按鈕。第49頁/共100頁圖8-13 基于可視關(guān)系標(biāo)識符的對象識別(3)智能識別(Smart Identification) 在這一階段,UFT組合使用一個測試對象類的基本屬性(Base Filter Properties)和一些可選屬性(Optional Filter Properties)來完成對象識別。 UFT利用基本屬性產(chǎn)生候選匹配對象的列表,然后通過逐項對比可選屬性,縮小候選匹配對象的范圍,直

21、到識別出唯一的對象。第50頁/共100頁圖8-14 智能識別中基本屬性和可選屬性的配置智能識別的配置第51頁/共100頁(4)順序標(biāo)識符(Ordinal Identifier) 順序標(biāo)識符是用來標(biāo)識一個對象相對于其它對象的順序的數(shù)字值。當(dāng)UFT發(fā)現(xiàn)有多個對象具有相同的屬性值而無法對它們進行唯一識別時,可以通過順序標(biāo)識符將它們區(qū)別開來。第52頁/共100頁三種類型的順序標(biāo)識符Index。識別對象時,UFT 可以將值分配給測試對象的Index 屬性以唯一地標(biāo)識對象。Location。識別對象時,UFT 可以將值分配給測試對象的Location 屬性以唯一地標(biāo)識對象。CreationTime。僅適用

22、于Browser對象。識別瀏覽器對象時,UFT將值分配給CreationTime標(biāo)識屬性。第53頁/共100頁8.2.4 自動化測試框架1、自動化測試框架的基本含義 框架提供了軟件系統(tǒng)整體或部分的可重用設(shè)計,是可以被開發(fā)者直接使用和擴展定制的應(yīng)用骨架。軟件重用從模塊和對象重用發(fā)展到構(gòu)件和框架重用,重用粒度不斷增大。 自動化測試框架是一種特殊類型的框架。第54頁/共100頁從廣義上來講: 自動化測試框架,是一組自動化測試的規(guī)范和測試腳本的基礎(chǔ)代碼,以及測試思想、方法和慣例的集合。從狹義上來講: 自動化測試框架是由一個或多個自動化測試基礎(chǔ)模塊、自動化測試管理模塊、自動化測試統(tǒng)計模塊等組成的工具集合

23、。第55頁/共100頁一個典型的自動化測試框架圖8-15 自動化測試框架的基本模塊包括測試用例管理模塊、自動化執(zhí)行控制器、報表生成模塊和測試日志模塊第56頁/共100頁各模塊的功能測試用例管理模塊包括用例的添加、修改、刪除等基本功能,也包括用例編寫模式、測試數(shù)據(jù)管理、可復(fù)用的測試用例庫管理等功能。自動運行控制器主要負(fù)責(zé)以什么方式執(zhí)行用例。第57頁/共100頁報表生成模塊主要負(fù)責(zé)用例執(zhí)行以后生成報表,報表一般為HTML格式。日志模塊主要用來記錄用例的執(zhí)行情況,以便于高效地追蹤用例執(zhí)行情況和分析用例失敗信息。第58頁/共100頁2、自動化測試腳本類型(1)線性腳本 線性腳本是由測試工具錄制并記錄軟

24、件操作過程和輸入數(shù)據(jù)所形成的腳本,通過回放來重復(fù)人工操作的過程,一般用于簡單測試或者作為基本腳本供修改后進一步使用。第59頁/共100頁用于測試計算器的加法功能線性腳本示例第60頁/共100頁(2)結(jié)構(gòu)化腳本 結(jié)構(gòu)化腳本類似于結(jié)構(gòu)化程序,具有順序、分支、循環(huán)等邏輯結(jié)構(gòu)。 結(jié)構(gòu)化腳本能夠體現(xiàn)模塊化與庫函數(shù)的思想。模塊化后的腳本可以支持分層的腳本結(jié)構(gòu),實現(xiàn)腳本之間的相互調(diào)用??梢员欢鄠€測試用例使用的腳本有時也被稱為共享腳本。第61頁/共100頁通過UFT檢查Mercury Tours站點(http:/www.newtours. )中是否存在User Name編輯框第62頁/共100頁(3)數(shù)據(jù)驅(qū)動

25、腳本 數(shù)據(jù)驅(qū)動腳本將測試數(shù)據(jù)和具體測試執(zhí)行過程進行分離,將測試輸入數(shù)據(jù)存儲在獨立的數(shù)據(jù)文件或數(shù)據(jù)庫中。 簡單來說就是執(zhí)行相同的測試步驟,使用不同的測試數(shù)據(jù)。第63頁/共100頁例如,測試軟件登錄功能時的數(shù)據(jù)驅(qū)動腳本如下第64頁/共100頁(4)關(guān)鍵字驅(qū)動腳本 關(guān)鍵字驅(qū)動腳本用一系列關(guān)鍵字指定要執(zhí)行的測試任務(wù)。關(guān)鍵字對應(yīng)封裝的業(yè)務(wù)邏輯,各種基本操作由關(guān)鍵字代表的函數(shù)完成。第65頁/共100頁圖8-16是一個通過Katalon Recorder生成的關(guān)鍵字驅(qū)動腳本,用于測試Mercury Tours站點的登錄功能。第66頁/共100頁3、自動化測試框架類型測試腳本模塊化框架測試庫架構(gòu)框架數(shù)據(jù)驅(qū)動測

26、試框架關(guān)鍵字驅(qū)動或表驅(qū)動測試框架混合測試自動化框架第67頁/共100頁(1)測試腳本模塊化框架(The Test Script Modularity Framework) 測試腳本模塊化框架的特點是將被測程序分解為多個邏輯模塊,對每個模塊都創(chuàng)建一個小而獨立的測試腳本,測試腳本中包含了各功能點的控件識別和業(yè)務(wù)邏輯操作。第68頁/共100頁(2)測試庫架構(gòu)框架(The Test Library Architecture Framework) 這種框架與腳本模塊化框架類似,同樣能夠產(chǎn)生高度模塊化的測試用例。不同的是,被測程序被分解為過程和函數(shù),而不是測試腳本。所有測試用例中的常用功能可以作為函數(shù)被存

27、儲在一個公共測試庫中(例如SQABasic Libraries、APIs、DLLs等)。第69頁/共100頁(3)數(shù)據(jù)驅(qū)動測試框架(The Data-Driven Testing Framework) 當(dāng)使用不同的輸入數(shù)據(jù)集多次測試相同功能時,不應(yīng)當(dāng)以硬編碼的形式在測試腳本中大量嵌入這些測試數(shù)據(jù),而是應(yīng)當(dāng)將其保存在XML文件、CSV文件、數(shù)據(jù)庫等外部數(shù)據(jù)源中。測試執(zhí)行時,通過腳本代碼將測試數(shù)據(jù)載入到腳本變量中。第70頁/共100頁(4)關(guān)鍵字驅(qū)動或表驅(qū)動測試框架(The Keyword-Driven or Table-Driven Testing Framework) 關(guān)鍵字驅(qū)動測試框架源于數(shù)

28、據(jù)驅(qū)動測試框架。在數(shù)據(jù)驅(qū)動測試框架中,數(shù)據(jù)文件中只包含測試數(shù)據(jù);而在關(guān)鍵字驅(qū)動框架中,數(shù)據(jù)文件中存儲的是關(guān)鍵字和測試數(shù)據(jù)。第71頁/共100頁(5)混合測試自動化框架(Hybrid Test Automation Framework) 自動化測試框架的主要目的是將不同層次的對象和邏輯進行抽象、分離與封裝,以便于把程序變更所引起的測試用例修改和維護工作量減少到最小。因此,實際工作中一般用到的自動化測試框架是一個混合框架。第72頁/共100頁圖8-17 混合測試自動化框架第73頁/共100頁8.3 測試工具的分類與選擇8.3.1 軟件測試工具分類1、商業(yè)測試工具 專業(yè)開發(fā)軟件測試工具的公司有很多,

29、其中以MI(Mercury Interactive)、IBM Rational和Micro Focus最為著名。第74頁/共100頁(1)MI的主要測試工具 MI開發(fā)的測試工具最著名的是LoadRunner、UFTQTPWinRunner和Quality Center Test Director。LoadRunner是測試人員都熟知的性能測試工具,能夠滿足企業(yè)級應(yīng)用,實現(xiàn)對C/S和B/S結(jié)構(gòu)軟件系統(tǒng)的性能測試。第75頁/共100頁UFTQTPWinRunner三者都是MI開發(fā)的功能測試工具。Quality Center Test Director是MI開發(fā)的測試管理工具。Test Direct

30、or(簡稱TD)是一個基于Web的測試管理系統(tǒng)能夠完成需求管理、測試計劃管理、測試用例管理和缺陷跟蹤管理。第76頁/共100頁(2)IBM Rational的主要測試工具IBM Rational公司的產(chǎn)品涵蓋了需求管理、軟件建模、配置管理等全方位的軟件工程CASE(Computer Assisted Software Engineering)工具,其產(chǎn)品的一個典型優(yōu)勢是幾乎所有的工具都支持跨平臺安裝。第77頁/共100頁IBM Rational主要有以下一些測試工具。功能測試工具可分為手動測試工具Rational Manual Tester和自動測試工具Rational Functional

31、Tester、Rational Robot。性能能測試工具包括Rational Performance Tester和Rational Robot。Rational Robot包括了功能測試和性能測試。第78頁/共100頁白盒測試工具包括Rational PurifyPlus和Rational Test RealTime。測試管理工具包括Rational TestManager和Rational ClearQuest。第79頁/共100頁(3)Micro Focus的主要測試工具 英國Micro Focus公司的測試工具很多源自于著名的Compuware公司和Segue公司。 Compuwar

32、e公司黑盒測試工具集QACenter里包括功能功能測試工具QARun、性能測試工具QALoad和測試管理工具QADirector。第80頁/共100頁 Segue公司是一個專業(yè)開發(fā)測試工具的廠商,其產(chǎn)品SilkTest、SilkPerformer完全可以和Mercury QTP、Loadrunner媲美。第81頁/共100頁表8-1 主要的商業(yè)測試工具第82頁/共100頁功能測試性能測試白盒測試測試管理HP MercuryUFTQTPLoadRunnerTest Director,Quality CenterIBM RationalRational Manual Tester, Rationa

33、l Functional Tester, Rational RobotRational Performance Tester, Rational RobotRational PurifyPlus/PureCoverage, Rational Test RealTimeRational TestManager, Rational ClearQuestMicro Focus(Compuware,Segue)QARun, Micro Focus TestPartner,Micro Focus SilkTestQALoad,Micro Focus SilkPerformerBoundsCheckerT

34、rueCoverageDevPartnerQADirector, TrackRecordTelelogicLogiscopeParasoftWebKingC+Test, JTest,.TEST, SOA TestProgramming ResearchQAC/ C+/JRadviewWebFTWebLoadTestView ManagerMicrosoftACT(Application Center Test)IntelliTest2、開源測試工具白盒測試工具功能測試工具性能測試工具測試管理工具第83頁/共100頁(1)白盒測試工具針對不同的程序語言有著不同的白盒測試工具,一般有以下幾種測試工

35、具。 例如JUnit(Java)、CppUnit(C+)、DotUnit(.Net)、HtmlUnit(HTML)、JsUnit(JavaScript)、PHPUnit(PHP)、PerlUnit(Pear)等。第84頁/共100頁(2)功能測試工具AutoIT用于測試基于Windows GUI操作的軟件。Ruby+Watir組合是近年非常流行的全免費自動化測試框架可以實現(xiàn)對Web應(yīng)用程序的自動化測試。Selenium支持Ruby、Java、Perl、Python等腳本語言,目前在國內(nèi)外日益流行。第85頁/共100頁(3)性能測試工具JMeter最初只是測試Web應(yīng)用,目前已經(jīng)能夠支持HTTP

36、/HTTPS、SOAP、JDBC、LDAP、JMS等。TestMaker可以和Seleinium、SoapUI集成,TestMarker只是更好地調(diào)度、監(jiān)控和管理測試的過程,監(jiān)控系統(tǒng)的性能指標(biāo),獲得測試結(jié)果。第86頁/共100頁ApacheBench能同時模擬多個并發(fā)請求,專門用于Web服務(wù)器的基準(zhǔn)測試。Grinder基于HTTP的測試可以由瀏覽器來記錄整個測試過程。Siege是一個壓力測試和評測工具,用于Web開發(fā)。第87頁/共100頁(4)測試管理工具測試管理工具開發(fā)難度較小,因此開源免費的產(chǎn)品很多,下面是一些常見工具。Bugzilla可與CVS進行無縫集成,當(dāng)前最成熟。Mantis是一款

37、Web缺陷管理工具,國內(nèi)使用較多。BugFree是一款輕量級的Web缺陷管理工具。TestLink可對測試需求、計劃、用例、執(zhí)行、缺陷報告等進行完整管理。第88頁/共100頁8.3.2 當(dāng)前最好的自動化測試工具2017-2018世界質(zhì)量報告中給出了世界排名前10的自動化測試工具。其中既包含了免費工具也包含了商業(yè)工具。(1)Selenium(開源)(2)Katalon Studio(免費)(3)UFT(商業(yè))(4)Watir(開源)(5)IBM Rational Functional Tester(商業(yè))第89頁/共100頁(6)TestComplete(商業(yè))(7)TestPlant eggPlant(商業(yè))(8)Tricentis Tosca(商業(yè))(9)Ranorex(商業(yè))(10)Robot Framework(開源)第90頁/共100頁8.3.3

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論