軟件測試技術(shù) 習題答案 朱少民 第二版_第1頁
軟件測試技術(shù) 習題答案 朱少民 第二版_第2頁
軟件測試技術(shù) 習題答案 朱少民 第二版_第3頁
軟件測試技術(shù) 習題答案 朱少民 第二版_第4頁
軟件測試技術(shù) 習題答案 朱少民 第二版_第5頁
已閱讀5頁,還剩46頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

目錄第章軟件測試概述.1第章軟件測試方法與過程.4第章黑盒測試.7第章白盒測試方法.13第章軟件測試管理及自動化測試基礎(chǔ).18第章WINRUNNER測試工具.19第章LOADRUNNER測試工具.21第章JUNIT.23PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建第1章軟件測試概述1.簡述軟件測試的意義。解:隨著計算機技術(shù)的迅速發(fā)展和廣泛深入的應用,軟件質(zhì)量問題已成為開發(fā)和使用軟件人員關(guān)注的焦點。而由于軟件本身的特性,軟件中的錯誤是不開避免的。不斷改進的開發(fā)技術(shù)和工具只能減少錯誤的發(fā)生,但是卻不可能完全避免錯誤。因此為了保證軟件質(zhì)量,必須對軟件進行測試。軟件測試是軟件開發(fā)中必不可少的環(huán)節(jié),是最有效的排除和防治軟件缺陷的手段,是保證軟件質(zhì)量、提高軟件可靠性的最重要手段。2.什么是軟件缺陷?它的表現(xiàn)形式有哪些?解:從產(chǎn)品內(nèi)部看,軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題;從外部看,軟件缺陷是系統(tǒng)所需實現(xiàn)的某種功能的失效或違背。軟)2;(能功的經(jīng)標明中已未達到產(chǎn)品說明書軟件)1(:以下幾種有表現(xiàn)形式主要的它當?shù)珣m未指出中未達到產(chǎn)品說明書軟件)3;(的錯誤會出現(xiàn)不指明中產(chǎn)品說明書了出現(xiàn)件難為軟件認軟件測試人員)5范圍;(的指出中產(chǎn)品說明書了超出能功軟件)4目標;(的達到以理解、不易使用,或者最終用戶認為該軟件使用效果不良。3.簡單分析軟件缺陷產(chǎn)生的原因,其中那個階段引入的缺陷最多,修復成本又最低?解:軟件缺陷產(chǎn)生的主要原因有:需求規(guī)格說明錯誤;設(shè)計錯誤;程序代碼有誤;其他。其中在需求分析階段引入的缺陷最多,修復的成本又最低。4.當用戶登錄某網(wǎng)站購物完畢并退出后,忽然想查查購物時付賬的總金額,于是按了瀏覽器左上角的“退回”按鈕,就又回到了退出前的網(wǎng)頁,你認為該購物軟件有缺陷嗎?如果有,屬于哪一類?解:有缺陷。其所屬類別與軟件產(chǎn)品說明書的要求有關(guān)。5.什么是軟件測試?簡述其目的與原則。解:軟件測試是為了盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種軟件缺陷而展開的貫穿整個軟件開發(fā)生命周期,對軟件產(chǎn)品(包括階段性產(chǎn)品)進行驗證和確認的活動過程。測試目的:(1)證明:獲取系統(tǒng)在可接受風險范圍內(nèi)可用的信心;嘗試在非正常情況和條件下的功能和特性;保證一個工作產(chǎn)品是完整的并且可用或可被集成。(2)檢測:發(fā)現(xiàn)缺陷、錯誤和系統(tǒng)不足;定義系統(tǒng)的能力和局限性;提供組件、工作產(chǎn)品和系統(tǒng)的質(zhì)量信息。(3)預防:澄清系統(tǒng)的規(guī)格和性能;提供預防或減少可能制造錯誤的信息;在過程中盡早檢測錯誤;確認問題和風險,并且提前確認解決這些問題和風險的途徑。測試過程中應注意和遵循的原則:(1)測試不是為了證明程序的正確性,而是為了證明程序不能工作。(2)測試應當有重點。(3)事先定義好產(chǎn)品的質(zhì)量標準。(4)軟件項目一啟動,軟件測試也就開始,而不是等到程序?qū)懲瓴砰_始進行測試。(5)窮舉測試是不可能的。(6)第三方進行測試會更客觀,更有效。(7)軟件測試計劃是做好軟件測試工作的前提。1PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建(8)測試用例是設(shè)計出來的,不是寫出來的。(9)對發(fā)現(xiàn)錯誤較多的程序段,應進行更深入的測試。(10)重視文檔,妥善保存一切測試過程文檔。6. 件測試階段是如何劃分的?解:軟件測試的階段劃分為:規(guī)格說明書審查;系統(tǒng)和程序設(shè)計審查;單元測試;集成測試;確認測試;系統(tǒng)測試;驗收測試。7. 簡述軟件開發(fā)的幾個模式,并說明每種模式對軟件測試的影響。解:大棒模式簡單,計劃、進度安排和正規(guī)開發(fā)過程幾乎沒有,其開發(fā)過程是非工程化的。大棒模式的軟件測試通常在開發(fā)任務(wù)完成后進行,很難回頭修復存在的問題,測試工作只是向客戶報告軟件經(jīng)過測試后發(fā)現(xiàn)的情況。邊寫邊改模式通常最初只有粗略的想法就進行簡單的設(shè)計,然后開始較長的反復編寫、測試和修復過程,在認為無法更精細地描述軟件產(chǎn)品要求時就發(fā)布產(chǎn)品。該模式下,軟件測試人員將和程序員一起陷入可能是長期的循環(huán)往復過程。瀑布模式將軟件生命周期的各項活動規(guī)定為按照固定順序相連的若干個階段性工作,形如瀑布流水,最終得到軟件產(chǎn)品。軟件測試在后期展開,使得開發(fā)中出現(xiàn)的問題直到開發(fā)后期才顯露,失去了及早糾正的機會。快速原型模式首先構(gòu)造一個功能簡單的原型系統(tǒng),然后通過對原型系統(tǒng)逐步求精,不斷擴充完善得到最終的軟件系統(tǒng)。原型系統(tǒng)在擴充完善過程中不斷被檢查、測試和修改。螺旋模式是瀑布模式與邊寫邊改模式演化結(jié)合的形式,并加入了風險評估所建立的軟件開發(fā)模式,其主要思想是在開始時不必詳細定義所有細節(jié),而是從小開始,定義重要功能,盡量實現(xiàn),接受客戶反饋,進入下一階段并重復上述過程,直到獲得最終產(chǎn)品。測試在每個階段都要進行,并從最初就參與。8. 簡述軟件測試過程。解:軟件測試過程主要包括如下6個活動:測試計劃;測試需求分析;測試設(shè)計;測試規(guī)程實現(xiàn);測試執(zhí)行;總結(jié)生成報告。9. “軟件測試能夠保證軟件的質(zhì)量”這句話對嗎?軟件測試和軟件質(zhì)量之間是什么關(guān)系?解:不對。軟件測試是保障軟件質(zhì)量的手段之一,但不是唯一手段。測試是產(chǎn)品高質(zhì)量的必要非充分條件,軟件測試不能決定軟件質(zhì)量。10. 判斷以下說法是否正確。(1)軟件測試和軟件調(diào)試是同一回事。(2)軟件測試是可以無窮盡的。(3)測試是為了證明軟件的正確性。(4)測試過程中應重視測試的執(zhí)行,可以輕視測試的設(shè)計。(5)測試不能修復所有的軟件故障。(6)因為測試工作簡單,對軟件產(chǎn)品影響不大,所以可以把測試作為新員工的一個過渡工作,或安排不合格的開發(fā)人員做測試。2PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建。正確)5(錯誤,)6)(4)(3)(2)(1(解:11. 簡述軟件開發(fā)進程與測試進程的關(guān)系。解:軟件測試是一個貫穿軟件開發(fā)生命周期的活動,它可以是一個與開發(fā)并行的過程,也可以是在開發(fā)完成某個階段任務(wù)之后的活動。3PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建第2章軟件測試方法與過程1對軟件測試的復雜性進行歸納分析。解:軟件測試的復雜性在于:無法對程序進行完全的測試;測試無法保證被測程序中無遺留錯誤;不能修復所有的軟件故障。2分別解釋什么是靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、人工測試和自動化測試。解:所謂靜態(tài)測試是指不運行被測軟件,僅通過分析或檢查等其他手段達到檢測的目的。所謂動態(tài)測試是指通過運行被測軟件,檢查運行結(jié)果與預期結(jié)果的差異,并分析運行效率和健壯性等性能。黑盒測試是指在對程序進行的功能抽象的基礎(chǔ)上,將程序劃分成功能單元,然后對每個功能單元生成測試數(shù)據(jù)進行測試。用這種方法進行測試時,被測程序被當作打不開的黑盒,因而無法了解其內(nèi)部構(gòu)造,因此又稱為功能測試。白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試,它是知道產(chǎn)品內(nèi)部工作過程,可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行,按照程序內(nèi)部的結(jié)構(gòu)測試程序,檢驗程序中的每條通路是否都有能按預定要求正確工作,而不顧它的功能。廣義上,人工測試是人為測試和手工測試的統(tǒng)稱。人為測試的主要方法有桌前檢查,代碼審查和走查。手工測試指的是在測試過程中,按測試計劃一步一步執(zhí)行程序,得出測試結(jié)果并進行分析的測試行為。自動化測試指的是利用測試工具來執(zhí)行測試,并進行測試結(jié)果分析的測試行為。3如果沒有軟件規(guī)格說明或需求文檔,可以進行動態(tài)黑盒測試嗎?為什么?解:不行。因為黑盒測試是基于軟件規(guī)格說明的測試。4在單元測試中,所謂單元是如何劃分的?解:單元測試的對象通常是軟件設(shè)計的最小邏輯單元,單元的劃分在面向過程的結(jié)構(gòu)化程序中一般是函數(shù)或子過程,在面向?qū)ο蟮某绦蛑锌梢允穷惢蝾惖某蓡T函數(shù)。5簡述單元測試的主要任務(wù)。解:單元測試的主要任務(wù)是:模塊接口測試;局部數(shù)據(jù)結(jié)構(gòu)測試;路徑測試;錯誤處理測試;邊界測試。6如果開發(fā)時間緊迫,是否可以跳過單元測試而直接進行集成測試?為什么?解:不可以。因為沒有經(jīng)過單元測試的模塊會遺留大量的缺陷到集成測試階段,而在集成測試階段對這些缺陷定位困難,導致后續(xù)工作展開困難,修復缺陷成本成指數(shù)級增長。7什么是驅(qū)動模塊和樁模塊?為下面的函數(shù)構(gòu)造一個驅(qū)動模塊。int divide(int a, int b)4PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建int c;if (b=0) printf(除數(shù)不能為0); return 0;c=a/b;return c;解:驅(qū)動模塊是用以模擬被測模塊的上級模塊,它接收測試數(shù)據(jù),傳送數(shù)據(jù)給被測模塊,啟動被測模塊,最后輸出實測結(jié)果。樁模塊用以模擬被測模塊工作過程中所調(diào)用的子模塊。函數(shù)驅(qū)動模塊:void main( )int x,y,z;scanf(“%d%d”,&x,&y);z=divide(x,y);printf(“%d”,z);8什么是回歸測試?什么時候進行回歸測試?解:回歸測試就是重新運行現(xiàn)有測試用例測試原有功能,以便確定變更是否達到了預期的目的,檢查變更是否損害了原有的正常功能。每當軟件發(fā)生變化時就應進行回歸測試。9集成測試有哪些不同的集成方法?簡述不同方法的特點。解:集成測試通常有一次性集成、自頂向下集成、自底向上集成和混合集成4種集成方法。一次性集成方法需要的測試用例數(shù)目少,測試方法簡單、易行。但是由于不可避免存在模塊間接口、全局數(shù)據(jù)結(jié)構(gòu)等方面的問題,所以一次運行成功的可能性不大;如果一次集成的模塊數(shù)量多,集成測試后可能會出現(xiàn)大量的錯誤,給程序的錯誤定位與修改帶來很大的麻煩;即使集成測試通過,也會遺漏很多錯誤進入系統(tǒng)測試。自頂向下集成在測試的過程中,可以較早地驗證主要的控制和判斷點;一般不需要驅(qū)動程序,減少了測試驅(qū)動程序開發(fā)和維護的費用;可以和開發(fā)設(shè)計工作一起并行執(zhí)行集成測試,能夠靈活的適應目標環(huán)境;容易進行故障隔離和錯誤定位。但是在測試時需要為每個模塊的下層模塊提供樁模塊,樁模塊的開發(fā)和維護費用大;樁模塊不能反映真實情況,重要數(shù)據(jù)不能及時回送到上層模塊,導致測試不充分;涉及復雜算法和真正I/O的底層模塊最易出問題,在后期才遇到導致過多的回歸測試。自底向上集成可以盡早的驗證底層模塊的行為;提高了測試效率;一般不需要樁模塊;容易對錯誤進行定位。但是直到最后一個模塊加進去之后才能看到整個系統(tǒng)的框架;驅(qū)動模塊的設(shè)計工作量大;不能及時發(fā)現(xiàn)高層模塊設(shè)計上的錯誤?;旌霞删哂凶皂斚蛳潞妥缘紫蛏蟽煞N集成策略的優(yōu)點,但是在被集成之前,中間層不能盡早得到充分的測試。10系統(tǒng)測試主要包括哪些內(nèi)容?解:系統(tǒng)測試主要包括強度測試、性能測試、恢復測試、安全測試、可靠性測試、安裝測試、5PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建容量測試和文檔測試。11驗收測試是由誰完成的?通常包含哪些過程?解:驗收測試是以用戶為主的測試,軟件開發(fā)人員和QA(質(zhì)量保證)人員也應參加。通常包含測試和測試過程。12分析比較面向?qū)ο蟮能浖y試與傳統(tǒng)的軟件測試的異同。解:傳統(tǒng)的單元測試的對象是軟件設(shè)計的最小單位模塊。當考慮面向?qū)ο筌浖r,單元的概念發(fā)生了變化,此時最小的可測試單位是封裝的類或?qū)ο?,而不再是個體的模塊。傳統(tǒng)單元測試主要關(guān)注模塊的算法實現(xiàn)和模塊接口間數(shù)據(jù)的傳遞,而面向?qū)ο蟮膯卧獪y試主要考察封裝在一個類中的方法和類的狀態(tài)行為。面向?qū)ο筌浖]有層次的控制結(jié)構(gòu),因此傳統(tǒng)的自頂向下和自底向上集成策略就不再適合,它主要有以下兩種集成策略:基于類間協(xié)作關(guān)系的橫向測試;基于類間繼承關(guān)系的縱向測試。系統(tǒng)測試一般不考慮內(nèi)部結(jié)構(gòu)和中間結(jié)果,因此面向?qū)ο筌浖到y(tǒng)測試與傳統(tǒng)的系統(tǒng)測試差別不大。面向?qū)ο筌浖y試的整體目標和傳統(tǒng)軟件測試的目標是一致的,即以最小的工作量發(fā)現(xiàn)盡可能多的錯誤,但是面向?qū)ο鬁y試的策略和戰(zhàn)術(shù)有很大不同。測試的視角擴大到包括復審分析和設(shè)計模型,此外,測試的焦點從過程構(gòu)件(模塊)移向了類。6PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建第3章黑盒測試1分析黑盒測試方法的特點。解:黑盒測試又稱為功能測試或數(shù)據(jù)驅(qū)動測試,主要針對軟件界面、軟件功能、外部數(shù)據(jù)庫訪問以及軟件初始化等方面進行測試。優(yōu)點:1)比較簡單,不需要了解程序內(nèi)部的代碼及實現(xiàn);2)與軟件的內(nèi)部實現(xiàn)無關(guān);3)從用戶角度出發(fā),能很容易的知道用戶會用到哪些功能,會遇到哪些問題;4)基于軟件開發(fā)文檔,所以也能知道軟件實現(xiàn)了文檔中的哪些功能;5)在做軟件自動化測試時較為方便。缺點:1)不可能覆蓋所有的代碼,覆蓋率較低,大概只能達到總代碼量的30%;2)自動化測試的復用性較低。2健壯等價類測試與標準等價類測試的主要區(qū)別是什么?解:主要區(qū)別在于健壯等價類測試在標準等價類的基礎(chǔ)上還要進行有效取值范圍之外的輸入(無效輸入)的測試。3試用等價分類法測試黨政管理系統(tǒng)中黨員出生年月的輸入設(shè)計是否符合要求,假設(shè)出生年月格式為yyyymmdd。解:輸入數(shù)據(jù)無效等價類有效等價類出生年月日8位數(shù)字字符有非數(shù)字字符少于8個數(shù)字符多于8個數(shù)字符對應數(shù)值在19090101-19900101之間19900101月份對應數(shù)值在1-12之間等于00 12日期對應值111,3,5,7,8,10,12月在1-31之間15等于00 124,6,9,11月在1-30之間163113閏年2月在1-29之間172,4,6,9,11月等于31 14非閏年2月在1-28之間182月等于30 19非閏年2月等于294找零錢最佳組合:假設(shè)商店貨品價格(R)皆不大于100元(且為整數(shù)),若顧客付款在100元內(nèi)(P),求找給顧客之最少貨幣個(張)數(shù)?(貨幣面值50元(N50),10元(N10),5元(N5),1元(N1)四種。試根據(jù)邊界值法設(shè)計測試用例。解:1)分析輸入的邊界情況:R100 0R=100 R100 R=P=100 PN10= 1 N10 = 0N5=1 N5=04N1=1 N1=03)分析規(guī)格中每一決策點之情形,以RR1,RR2,RR3表示計算要找50,10,5元貨幣數(shù)時的剩余金額。R100 R100 P=50 RR2=10 RR3=54)根據(jù)上述的輸入/輸出條件組合出可能的情況:R 100R = 00 R 1000 R = 100, P R0 R = 100, R = P = 100, RR = 500 R = 100, R = P = 100, RR = 490 R = 100, R = P = 100, RR = 100 R = 100, R = P = 100, RR = 90 R = 100, R = P = 100, RR = 50 R = 100, R = P = 100, RR = 40 R = 100, R = P = 100, RR = 10 R = 100, R = P = 100, RR = 05)為滿足以上各種情形,測試用例設(shè)計如下:測試用例貨品價格R付款金額Ptest1 101 -test2 0 -test3 -1 -test4 100 101test5 100 99test6 50 100test7 51 100test8 90 100test9 91 100test10 95 100test11 96 100test12 99 100test13 100 1005試為三角形問題中的直角三角形開發(fā)一個決策表和相應的測試用例。注意,會有等腰直角三角形。解:判斷構(gòu)成的是否為直角三角形的問題的決策表設(shè)計如下:c1:ab+c? FTTTTTTTTTTc2:ba+c? -FTTTTTTTTT8PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建c3:c=80,y=80錯誤!未找到引用源。x=80,y80錯誤!未找到引用源。x=80錯誤!未找到引用源。x80,y=90,y=90,x+y=140錯誤!未找到引用源。x=90,y=140錯誤!未找到引用源。x=90,x+y=140錯誤!未找到引用源。x90,y=140錯誤!未找到引用源。x=90,y=90,x+y=90,y90,x+y140錯誤!未找到引用源。x=90,x+y140錯誤!未找到引用源。x90,y90,x+y2 & b4 | d2,b4,d2,b4,d=5錯誤!未找到引用源。a2,b3,c=4,d2,b3,c=5錯誤!未找到引用源。a2,b=3,c4,d2,b=3, c4,d=5錯誤!未找到引用源。a2,b=3, c=4,d2,b=3, c=5錯誤!未找到引用源。a=2,b4,d5錯誤!未找到引用源。a=2, b4,d=5錯誤!未找到引用源。a=2, b3,c=4,d5錯誤!未找到引用源。a=2, b3,c=5錯誤!未找到引用源。a=3,c4,d5錯誤!未找到引用源。a=3, c4,d=5錯誤!未找到引用源。a=3, c=4,d5錯誤!未找到引用源。a=3, c=5測試數(shù)據(jù)略5針對test函數(shù)按照基本路徑測試方法設(shè)計測試用例。int Test(int i_count, int i_flag)int i_temp = 0;while (i_count0)if (0 = i_flag)i_temp = i_count + 100;break;else15PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建if (1 = i_flag)i_temp = i_temp + 10;elsei_temp = i_temp + 20;i_count-;return i_temp;解:int Test(int i_count, int i_flag)1. int i_temp=0;2. while (i_count0)3. If (0=i_flag)4. i_temp=i_count+100;5. break;6. else7. If (1=i_flag)8. i_temp=i_temp+10;9. else10. i_temp=i_temp+20;11. i_count-;12. return i_temp;程序控制流圖:16PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建134,5 6,713. 9,1011122134,5 6,714. 9,1011122程序環(huán)路復雜度:CC=4基本路徑集:path1 1-2-3-6-7-8-11-2-12Path2 1-2-12Path3 1-2-3-4-5-12Path4 1-2-3-6-7-9-10-11-2-12設(shè)計測試用例:用例ID i_count i_flag 預期輸出test1 1 1 10test 2 0 2 0test 3 2 0 102test 4 1 3 206對如圖15. 15所示的N-S圖,計算所需的最少測試用例數(shù)。YpNgY NqY Nfm naY Nb cY h N圖4.15 練習題6解:(2+2*2)*2=1217PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建.第5章軟件測試管理及自動化測試基礎(chǔ)1簡述軟件測試自動化的意義。測試的歸回版本進行新對軟件低降)2;(率測試效)提高1(是:意義的化動自解:軟件測試更好地)5;(性重復性和可致一具有)4;(完成的測試或難以完成手工測試不能)3;(銷開。任度信軟件加增,風險低降)6;(資源用利2在運用軟件自動化測試時,應注意哪些缺點和事項?大現(xiàn),可能發(fā)時行次運首測試)2;(率測試的效低降測試可能化動自軟件)1(:意解:應注量錯誤,但當進行過多次測試后,發(fā)現(xiàn)錯誤的機率會相對較小,除非對軟件進行了修改或在測化動自則,致一不或少檔文、差織組,測試的驗經(jīng)測試乏缺果如)3;(行運下境的環(huán)同不和技力問題的能決解備不具果如,產(chǎn)品的技術(shù)第三方為作技術(shù)問題。)4;(差較比果試的效術(shù)支持或者產(chǎn)品適應環(huán)境變化的能力不強,將使得軟件自動化工具的作用大大降低。3軟件測試工具主要分為哪個大類?解:根據(jù)測試方法不同,分為白盒測試工具和黑盒測試工具。根據(jù)測試的對象和目的,分為單元測試工具、功能測試工具、負載測試工具、性能測試工具和測試管理工具等。4了解時下常用的自動化測試用具,并對這些工具進行針對性說明。解:略。5簡述軟件測試管理過程。解:首先由一位對整個系統(tǒng)設(shè)計熟悉的設(shè)計人員編寫測試大綱,明確測試的內(nèi)容和測試通過的準則,設(shè)計完整合理的測試用例,以便系統(tǒng)實現(xiàn)后進行全面測試。然后在實現(xiàn)組將所開發(fā)的程序經(jīng)驗證后,提交測試組,由測試負責人組織測試,測試一般可按下列方式組織: (1)測試人員仔細閱讀有關(guān)資料,包括規(guī)格說明、設(shè)計文檔、使用說明書及在設(shè)計過程中形成的測試大綱、測試內(nèi)容及測試的通過準則,全面熟悉系統(tǒng),編寫測試計劃,設(shè)計測試用例,作好測試前的準備工作。(2)為了保證測試的質(zhì)量,將測試過程分成幾個階段,即:代碼審查、單元測試、集成測試、確認測試和系統(tǒng)測試。6簡述軟件測試管理的主要功能。解:軟件測試管理的主要功能是:測試控制對象的編輯和管理;測試流程控制和管理;統(tǒng)計分析和決策支持7試選擇一個小型的應用系統(tǒng),做功能測試計劃并設(shè)計測試用例。解:略。18PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建第6章WinRunner測試工具1列舉幾種WR學習軟件GUI的不同方式。解:(1)使用RapidTest Script wizard 學習軟件每個窗體中所有GUI對象的屬性。(2)通過錄制腳本的方法學習被錄制的那部分軟件中所有的GUI對象的屬性。(3)使用GUI Map Editor 學習單個GUI對象、窗體或某個窗體中所有GUI對象的屬性。2分別簡述WR中同步點和檢查點的作用。解:當測試人員執(zhí)行測試時,所測試的應用程序每次操作的響應時間并不一定,有時快,有時慢,導致執(zhí)行輸入動作的時間也需要等待。在測試腳本中插入同步點,當WinRunner執(zhí)行到同步點時,會暫停執(zhí)行以等待應用程序某些狀態(tài)的改變后,再繼續(xù)執(zhí)行,以避免應用程序響應的時間超過WinRunner 等待的時間而導致測試執(zhí)行失敗。設(shè)定檢查點可以檢查所設(shè)定區(qū)域的顯示是否和預期結(jié)果相符。通過檢查點的設(shè)置以及對各點處輸出信息的編程定義,可以在腳本運行結(jié)果單中查看各項測試內(nèi)容是否都已通過。在功能測試中,檢查點可以用在以下兩個方面:檢查應用程序經(jīng)過修改后對象狀態(tài)是否發(fā)生變化;檢查對象數(shù)據(jù)是否和預期數(shù)據(jù)一致。3比較WinRunner中GUIde Map File per Test和Global GUI Map File兩種模式的區(qū)別。解:兩種模式GUI Map File per Test Global GUI Map File方法在測試的過程中將自動保GUI信息,打開測試時可以自動加載GUI文件在測試的過程中需要保存GUI,當應用程序改變時必須更新GUI文件優(yōu)點1. 每個測試都有自己的GUI文件2. 不必保存或加載GUI3. 維護和修改簡單(重錄一次即可)1. 當對象或窗體的描述改變,只需把GUI 文件里對應的屬性作相應的修改2. 容易維護和更新(無須重錄)缺點只要應用程序的GUI 改變,每個測試的GUI 文件都要重錄或修改當新建GUI或運行測試腳本時必須保存或裝載GUI文件建議適用于初學者或被測軟件的GUI不會產(chǎn)生變化適用于經(jīng)驗豐富的WinRunner 使用者,或被測軟件的GUI可能會經(jīng)常產(chǎn)生變化4簡述利用WinRunner進行測試的過程可分為哪幾個階段,即操作步驟是什么?;試測試調(diào))3;(創(chuàng)建測試)2;(GUImap創(chuàng)建)1(:階段個六以下為過程分的測試WR解:(4)執(zhí)行測試;(5)查看測試結(jié)果;(6)報告發(fā)現(xiàn)的錯誤。5給出WinRunner中將測試腳本轉(zhuǎn)換為數(shù)據(jù)驅(qū)動測試腳本的一種實現(xiàn)步驟。19PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建解:可以通過下列步驟將測試腳本轉(zhuǎn)換成數(shù)據(jù)驅(qū)動測試腳本:(1)加上開啟及關(guān)閉數(shù)據(jù)表的化數(shù)參值點的與檢查值定固的制錄將)3;(數(shù)據(jù)筆一每的表數(shù)據(jù)取讀并環(huán)循加上)2;(令指為數(shù)據(jù)表的字段值。6仿照實例4,在Flight Reservation樣本軟件的Flight 4B版本中建立GUI 對象檢查點。解:略。7仿照實例5,在Flight Reservation樣本軟件的Flight 4B版本中建立圖像檢查點。解:略。8仿照實例8,在Flight Reservation樣本軟件的Flight 4B版本中練習文字檢查點的應用。解:略。9仿照實例8,在Flight Reservation樣本軟件的Flight 4B版本中執(zhí)行批次測試。解:略。10仿照計算器加法功能的測試,完成對Windows的計算器減法、乘法和除法的測試。解:略。11思考利用WR測試網(wǎng)易郵箱的登錄模塊。解:略。20PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建第7章LoadRunner測試工具1. 試用LoadRunner 所給的示例,根據(jù)自己的理解設(shè)計測試,制定負載測試計劃、開發(fā)負載測試腳本、創(chuàng)建運行場景、運行測試以及依據(jù)結(jié)果利用Analysis 分析結(jié)果。解:略2. 如何利用LoadRunner判斷HTTP服務(wù)器的返回狀態(tài)。解:可以利用LR的內(nèi)置函數(shù)web_get_int_property判斷HTTP服務(wù)器的返回狀態(tài)。例如:#include web_api.hAction()int HttpRetCode;web_url(my_home,URL=http:/myhomeurl,TargetFrame=_TOP, LAST);HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);if (HttpRetCode = 200)lr_log_message(The scrpt successfully accessed the My_home home page);elselr_log_message(The scrpt failed to access the My_home home page );return 0;3. 一個公司的系統(tǒng)上線以后,用戶分布在各個不同的地區(qū),而且接入系統(tǒng)的方式和帶寬也不同,這種情況下進行性能測試,如何保證更加真實的模擬用戶行為?用LoadRunner可以做到嗎?解:可以。在Visual User Generator里面可以通過RTS(runTimeSetting)來模擬一個單個用戶更加真實的行為,比如思考時間、網(wǎng)絡(luò)帶寬、是否清除cache等,同樣的也可在場景中進行設(shè)置。而且LoadRunner提供設(shè)置不同用戶組不同RunTimeSetting的功能。以達到模擬不同用戶行為的更加真實組合。例如:假設(shè)有三種不同帶寬的用戶,而且上傳和下載的帶寬也有所不同,那么可以錄制兩個腳本,分別模擬上傳和下載的用戶行為,再在Controller里面,建立六個不同的腳本組,腳本組的用戶數(shù)可以按照絕對或者百比分的方法分布。比如100,50,200用戶或者20%,40%,40%等。然后設(shè)置不同的帶寬和分布情況。這樣不同用戶組的虛擬用戶模擬出來的就是不同帶寬的用戶實際接入情況。4. 在web應用下,模擬十個用戶并發(fā)進行數(shù)據(jù)的添加,結(jié)果每次執(zhí)行全部成功,但是數(shù)據(jù)卻不是十條,每次數(shù)據(jù)不一樣,但是都比十小。這種情況產(chǎn)生的原因是什么?解:是數(shù)據(jù)庫的問題。大多數(shù)的數(shù)據(jù)庫都有記錄鎖的問題,第一次的數(shù)據(jù)操作沒有commit之前,第二次對同樣表進行的操作可能就沒有辦法成功,所以每次數(shù)據(jù)的條數(shù)都達不到十條。21PDF 文件使用 pdfFactory Pro 試用版本創(chuàng)建又因為每次的操作服務(wù)器的響應時間是不同的,所以不同虛擬用戶的提交時間也是不同的,這樣就導致每次提交成功的數(shù)據(jù)量不一致,導致每次結(jié)果的條數(shù)可能是不同的。5. 在LoadRunner下如何讓多個場景輪流執(zhí)行?解:為每個場景設(shè)置一個Group。點擊Edit Schedule-選擇Schedule by Group-設(shè)置Start whengroup XXX finishes,就可以實現(xiàn)多個場景輪流執(zhí)行。6. 請解釋LoadRunner下最大并發(fā)用戶數(shù)、業(yè)務(wù)操作響應時間、服務(wù)器資源監(jiān)控指標的含義與用途。解:最大并發(fā)用戶數(shù)是指應用系統(tǒng)在當前環(huán)境下能承受的最大并發(fā)的用戶數(shù)。用來考察某系統(tǒng)的最大負載;在LoadRunner“事務(wù)性能摘要”圖中可以獲得業(yè)務(wù)操作的響應時間最大值、最小值和平均值,重

溫馨提示

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

評論

0/150

提交評論