第六章 軟件測試的度量_第1頁
第六章 軟件測試的度量_第2頁
第六章 軟件測試的度量_第3頁
第六章 軟件測試的度量_第4頁
第六章 軟件測試的度量_第5頁
已閱讀5頁,還剩65頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

第六章

軟件測試的度量授課教師:

鄭煒第六章軟件測試的度量6.1軟件測試度量簡介6.1.1軟件測試度量的目的6.1.2軟件測試度量的難度6.1.3軟件測試人員工作質(zhì)量的衡量6.2軟件測試的度量及其應(yīng)用6.2.1軟件缺陷的數(shù)量6.2.2軟件缺陷的價值6.2.3軟件缺陷的定性評估6.2.4軟件缺陷綜合評價模型6.2.5測試覆蓋率統(tǒng)計第六章軟件測試的度量6.3軟件測試常見的度量類型6.3.1手工測試度量6.3.2性能測試度量6.3.3自動化測試度量6.3.4通用度量6.1.1軟件測試度量的目的軟件度量度量是指對一個系統(tǒng)或過程的某些屬性方面的衡量。軟件的度量包括對軟件產(chǎn)品自身的測量,以及產(chǎn)生軟件產(chǎn)品過程的測量。為了評估軟件過程、產(chǎn)品,以及服務(wù)而使用的度量稱作軟件度量。6.1.1軟件測試度量的目的軟件測試度量軟件測試的度量包括對軟件測試產(chǎn)出物的測量,以及軟件測試過程的測量。軟件測試中的度量一般有如下目的:●判斷軟件測試的有效性。

●判斷軟件測試的完整性。

●判斷所測試的軟件產(chǎn)品的質(zhì)量。

●分析和改進軟件測試過程。6.1.1軟件測試度量的目的度量框架度量的數(shù)據(jù)構(gòu)成一個層次化的體系,就是度量框架??蚣艿纳蠈邮嵌攘恐笜耍‵actor),下層是直接度量(Metrics)。度量指標—產(chǎn)品或過程的特征—根據(jù)直接度量計算直接度量

—直接收集到的數(shù)據(jù)6.1.1軟件測試度量的目的軟件度量與軟件測試度量及測試人員的關(guān)系6.1.1軟件測試度量的目的軟件測試度量應(yīng)該遵循以下原則(1)要制訂明確的軟件測試度量目標。(2)軟件測試度量標準的定義應(yīng)該具有一致性、客觀性。(3)軟件測試度量的方法應(yīng)該盡可能簡單、可計算。(4)軟件測試度量數(shù)據(jù)的收集應(yīng)該盡可能自動化。6.1.1軟件測試度量的目的開發(fā)人員、測試人員及軟件產(chǎn)品之間的關(guān)系6.1.2軟件測試度量的難度影響產(chǎn)品質(zhì)量的因素如下6.1.2軟件測試度量的難度軟件測試度量的難度:-不能直接從產(chǎn)品的質(zhì)量反映測試的效果-應(yīng)該從軟件產(chǎn)品的度量轉(zhuǎn)移到測試產(chǎn)出物的度量,以及測試過程的度量測試度量如圖所示6.1.3軟件測試人員工作質(zhì)量的衡量性能測試:測試人員是測試過程的核心人物,測試人員的工作質(zhì)量會極大地影響測試的質(zhì)量及產(chǎn)品的質(zhì)量。素質(zhì)要求不斷學習的能力保持懷疑態(tài)度耐心、細心、信心團隊合作責任心溝通能力6.1.3軟件測試人員工作質(zhì)量的衡量技能要求:1.業(yè)務(wù)知識:測試人員對業(yè)務(wù)知識了解得越多,測試就越貼近用戶的實際需求。并且測試發(fā)現(xiàn)的軟件缺陷也是用戶非常關(guān)注的軟件缺陷,同時還是項目經(jīng)理、開發(fā)人員都會認為很重要的軟件缺陷。2.產(chǎn)品設(shè)計知識:測試人員對軟件產(chǎn)品相關(guān)的信息了解得越多,對測試越有利;對軟件產(chǎn)品設(shè)計、軟件架構(gòu)方面的信息了解得越多,越有利于把測試進行得更加深入,測試的范圍也會越廣。3.軟件架構(gòu)知識:對于產(chǎn)品知識了解得越多,測試就能越深入產(chǎn)品的核心位置

例:如果一個系剛成立,尚無學生,我們就無法把這個系及其系主任的信息存入數(shù)據(jù)庫。⒋統(tǒng)一建模語言(UnifiedModelingLanguage,UML):現(xiàn)在,大部分軟件開發(fā)組織都在使用UML指導(dǎo)設(shè)計和開發(fā)。6.1.3軟件測試人員工作質(zhì)量的衡量5.測試工具:常用功能自動化測試工具廠商工具名稱HPMercuryQuickTestProMicroFocusTestPartnerMicroFocusSilkTestIBMRationalRobotIBMRationalFunctionalTesterParasoftWebKingOraclee-TesterAutomateQATestCompleteSeaStoneSoftwareEggPlantMicrosoftVisualStudioTestEditionSoftwareResearcheValid開源Selenium開源WebInject開源Watir6.1.3軟件測試人員工作質(zhì)量的衡量6.不同的測試手段和測試工具:不同的項目采用的技術(shù)手段一般不一樣,采用的平臺、語言、開發(fā)工具、控件一般也不盡相同。例如,同樣是性能測試,在項目A中能夠使用LoadRunner錄制腳本,但是到了項目B就錄制不下來。7.開發(fā)工具:測試人員有必要掌握開發(fā)工具的一些基本操作,這樣對測試過程和問題重現(xiàn)等會起到事半功倍的作用。而且,如果進行白盒測試,對開發(fā)工具的掌握就更不可或缺了8.用戶心理學:測試應(yīng)該始終站在用戶、使用者的角度去考慮問題,而不應(yīng)該站在開發(fā)人員、實現(xiàn)者的角度考慮問題。9.界面設(shè)計中的3種模型:設(shè)計者模型、實現(xiàn)者模型和用戶模型6.1.3軟件測試人員工作質(zhì)量的衡量10.人機交互認知心理學:人機交互是一個從用戶體驗的角度出發(fā)考慮用戶感受的過程??紤]到用戶心理學和認知科學等,測試人員不得不根據(jù)以下基本原則指導(dǎo)界面測試。11.編程技能:編程技能未必是必不可缺的技能,但是如果掌握基本的編程技巧,則會對測試有事半功倍的效果。12.腳本語言:不需要追求精致的語言應(yīng)用,不追求完美的可重用性,甚至在有些時候也不會追求性能和效率,但是歸根結(jié)底,需要的是快速、能解決實際的問題13.文檔能力:一個優(yōu)秀的測試人員應(yīng)該善于利用這些書面的溝通方式來表達自

己的觀點、體現(xiàn)自己的能力和價值第六章軟件測試的度量6.1軟件測試度量簡介6.2軟件測試的度量及其應(yīng)用6.2.1軟件缺陷的數(shù)量6.2.2軟件缺陷的價值6.2.3軟件缺陷的定性評估6.2.4軟件缺陷綜合評價模型6.2.5測試覆蓋率統(tǒng)計6.2.1軟件缺陷的數(shù)量軟件缺陷的數(shù)量(1)利用軟件缺陷數(shù)量來考核測試效率。如果在考核過程中發(fā)現(xiàn)的漏洞越多,那么說明這個測試人員的測試效率越高,測試能力越強。(2)發(fā)現(xiàn)軟件缺陷數(shù)量的多少并不能完全證明測試人員的能力。但是如果把軟件缺陷數(shù)量加上一些前置條件(如軟件缺陷的嚴重程度),就會有一定的說明意義。6.2.1軟件缺陷的數(shù)量在同一個項目中,A、B兩個測試人員參與同樣的測試工作,統(tǒng)計出如下數(shù)據(jù):測試人員A:發(fā)現(xiàn)級別為1的軟件缺陷100個,

級別為2的軟件缺陷150個,

級別為3的軟件缺陷250個。測試人員B:

發(fā)現(xiàn)級別為1的軟件缺陷10個,

級別為2的軟件缺陷200個,

級別為3的軟件缺陷350個。

雖然測試人員B發(fā)現(xiàn)的軟件缺陷比測試人員A要多一些,但是不會認為測試人員A比測試人員B遜色,甚至可以認為測試人員A要表現(xiàn)得更加優(yōu)秀一些,因為測試人員A發(fā)現(xiàn)了大部分嚴重的軟件缺陷6.2.2軟件缺陷的價值按軟件缺陷的嚴重程度分級,然后每個級別的權(quán)值由高到低對應(yīng)僅憑軟件缺陷數(shù)量的多少顯然不能完全說明測試人員的能力,正確的做法應(yīng)該是在軟件缺陷數(shù)量度量的基礎(chǔ)上加入以下前提條件。(1)給軟件缺陷加權(quán)(2)度量篩選后的軟件缺陷6.2.2軟件缺陷的價值

加權(quán)法雖然科學,但是如果基于未加過濾的軟件缺陷來計算,則會多少有些不公平。

解決方法:制訂軟件缺陷級別評估規(guī)范,用于指導(dǎo)測試人員進行軟件缺陷等級的劃分。

軟件缺陷的質(zhì)量與測試的質(zhì)量如圖6.2.3軟件缺陷的定性評估對于軟件缺陷分析,常用的主要參數(shù)有以下4個:1.狀態(tài):

軟件缺陷的當前狀態(tài)。2.優(yōu)先級:

必須處理和解決的軟件缺陷的相對重要性。3.嚴重性:

對最終用戶、組織或者第三方的影響等。4.起源:

導(dǎo)致軟件缺陷的起源故障以及其位置,或者排除該軟件

缺陷需要修復(fù)的構(gòu)件。6.2.3軟件缺陷的定性評估軟件測試的軟件缺陷評估可以依據(jù)以下5類進行度量:1.軟件缺陷發(fā)現(xiàn)率:將發(fā)現(xiàn)的軟件缺陷數(shù)量作為時間的函數(shù)來評估。創(chuàng)建軟件缺陷趨勢圖和報告,如圖所示。6.2.3軟件缺陷的定性評估2.軟件缺陷潛伏期:

軟件缺陷潛伏期是一種特殊類型的軟件缺陷分析度量。軟件缺陷潛伏期報告顯示軟件缺陷處于特定狀態(tài)下的時間長短。實際測試工作中,發(fā)現(xiàn)越晚,危害就越大,修復(fù)成本就越高。3.軟件缺陷分布:

軟件缺陷分布是一種以平均值來估算軟件缺陷的分布值。程序代碼通常是以千行為單位,軟件缺陷分布度量使用下面的公式計算:軟件缺陷密度

=軟件缺陷數(shù)量代碼行或功能點的數(shù)量6.2.3軟件缺陷的定性評估4.整體軟件質(zhì)量、軟件缺陷注入率和清除率:

設(shè)F為描述軟件規(guī)模用的功能點;D1為軟件開發(fā)過程中發(fā)現(xiàn)的所有軟件缺陷數(shù);D2為軟件使用后發(fā)現(xiàn)的軟件缺陷數(shù);D為發(fā)現(xiàn)軟件缺陷的總數(shù),則D=D1+D2對于一個軟件項目,可以從不同角度來估算軟件的質(zhì)量、軟件缺陷注入率和清除率:

6.2.3軟件缺陷的定性評估5.整體軟件缺陷清除率:

①一級、二級bug修復(fù)率達到100%。②三級、四級bug修復(fù)率達到80%以上。③五級bug修復(fù)率應(yīng)該達到60%以上。除了必要的定量軟件缺陷價值評估外,還可以加入定性的評估。定性評估是指對測試人員發(fā)現(xiàn)的軟件缺陷質(zhì)量進行相對主觀的衡量,可包括以下方面的評價:①軟件缺陷的類型分布。②軟件缺陷重現(xiàn)率。③軟件缺陷錄入的清晰程度、簡明程度等。④軟件缺陷的新穎性。6.2.4軟件缺陷綜合評價模型一個合格的軟件缺陷報告應(yīng)該包括完整的內(nèi)容,至少包括:6.2.4軟件缺陷綜合評價模型在加入定性的評估后,可以形成一個如圖所示的軟件缺陷綜合評價模型:6.2.5測試覆蓋率統(tǒng)計統(tǒng)計測試的覆蓋率是一種衡量測試工作的方法。測試覆蓋率可分為:

代碼行覆蓋率、

功能模塊覆蓋率、

數(shù)據(jù)庫覆蓋率和需求覆蓋率等。6.2.5測試覆蓋率統(tǒng)計(1)代碼行覆蓋率代碼行覆蓋率=(已執(zhí)行測試的代碼行/總的代碼行)×100%代碼覆蓋程度的度量方式是有很多種的,這里介紹一下最常用的幾種,詳細內(nèi)容參見4.2.2小節(jié)。①

語句覆蓋:它度量程序中每條語句是否被測試到了。②

判定覆蓋:又稱分支覆蓋、所有邊界覆蓋、基本路徑覆蓋。它度

量程序中每個判定的分支是否都被測試到了。③

條件覆蓋:它度量判定中的每個子表達式結(jié)果true和false是否都

被測試到了。④

路徑覆蓋:又稱斷言覆蓋。它度量函數(shù)的每個分支是否都被執(zhí)行

了。測試期望所有可能的分支都執(zhí)行一遍,有多個分

支嵌套時需要對多個分支進行排列組合,可想而知,

測試路徑隨著分支數(shù)量的增加而呈指數(shù)級別增加。6.2.5測試覆蓋率統(tǒng)計如圖,用C++test得到代碼行覆蓋率的結(jié)果:6.2.5測試覆蓋率統(tǒng)計

代碼行覆蓋率只能代表測試過哪些代碼,不能代表是否測試好這些代碼。不能追求過高的代碼行覆蓋率,因為有些代碼只有在非常罕見的情況下才能出現(xiàn)。

因而,測試人員不能盲目追求代碼行覆蓋率,而應(yīng)該想辦法設(shè)計更多更好的測試用例,哪怕多設(shè)計出來的測試用例對代碼行覆蓋率一點影響也沒有。6.2.5測試覆蓋率統(tǒng)計有些異常情況是很難出現(xiàn)的,如“OutOfMemoryException”;有些異常則不會出現(xiàn),如果程序代碼寫得正確,如“DivideByZeroException”,那么這些異常相對應(yīng)的代碼就很可能不會被測試執(zhí)行到。6.2.5測試覆蓋率統(tǒng)計代碼行覆蓋率只能作為測試充分程度的參考,因為即使代碼行覆蓋率達到100%也很可能是測試不充分的例如,下面的示例代碼:如果變量a和b是輸入?yún)?shù),那么只要a或者b有一個等于1就可以覆蓋所有代碼行。但是其他使用到a或b的地方則有可能受到不同取值的影響而產(chǎn)生不同的結(jié)果。如果僅僅滿足于代碼覆蓋,那么測試顯然是不夠充分的。6.2.5測試覆蓋率統(tǒng)計(2)功能模塊覆蓋率功能模塊覆蓋率是一種比較粗的衡量方式。它主要用在系統(tǒng)功能上,或者包括很多子系統(tǒng)、子模塊的產(chǎn)品上,并且通常在回歸測試時衡量測試的覆蓋面。計算公式為:功能模塊覆蓋率=已執(zhí)行測試的功能模塊數(shù)/總的功能模塊數(shù)×100%6.2.5測試覆蓋率統(tǒng)計注意:在制訂功能模塊覆蓋率的衡量標準時,需要注意系統(tǒng)的各個功能模塊之間是否是有關(guān)聯(lián)的。例如,測試人員在測試庫存模塊時,可能需要在基礎(chǔ)配置模塊中先初始化一些庫存信息,而這也就同時測試了基礎(chǔ)配置模塊的一部分功能;另外,有些模塊在單元測試中已經(jīng)詳細地測試,且核心代碼已經(jīng)受控,則沒有必要每次都進行詳細的測試,因此不能每次都要求具有很高的功能模塊覆蓋率。假設(shè)某個項目包括m個主要功能模塊,在某次測試中,測試人員對其中的n個功能模塊進行了測試,其他功能模塊并未進行測試,則可統(tǒng)計出功能模塊覆蓋率為n/m。此情況統(tǒng)計功能模塊覆蓋率是沒有意義的。6.2.5測試覆蓋率統(tǒng)計(3)數(shù)據(jù)庫覆蓋率

除了功能模塊覆蓋率,還有一種覆蓋率統(tǒng)計方法是介于代碼行覆

蓋率和功能模塊覆蓋率之間的,叫作數(shù)據(jù)庫覆蓋率。數(shù)據(jù)庫覆蓋率指的是測試人員測試的功能模塊對數(shù)據(jù)庫表的訪問面積的覆蓋率。計算公式為:數(shù)據(jù)庫覆蓋率=SQL中出現(xiàn)的數(shù)據(jù)庫的對象數(shù)/數(shù)據(jù)庫總的對象數(shù)×100%(4)需求覆蓋率需求覆蓋率是基于需求項的覆蓋度量,主要通過分析測試用例的執(zhí)

行情況來衡量對需求的滿足程度。計算公式為:需求覆蓋率=被驗證到的需求數(shù)量/總的需求數(shù)量×100%第六章軟件測試的度量6.3軟件測試常見的度量類型6.3.1手工測試度量6.3.2性能測試度量6.3.3自動化測試度量6.3.4通用度量6.3.1手工測試度量不同的軟件測試度量如圖所示6.3.1手工測試度量幾種手工測試度量如下:(1)測試用例生產(chǎn)率該度量基于測試用例編寫的生產(chǎn)率,這些測試用例有確定的結(jié)果。測試用例生產(chǎn)率(TestCaseProductivity,TCP)的計算公式如下:測試用例生產(chǎn)率=總原始測試步驟(單位:步驟/小時)工作時間(小時)6.3.1手工測試度量測試例子結(jié)論為8小時編寫183個測試步驟,則TCP=183/8≈22.8,因此可以知道測試用例生產(chǎn)率為23步驟/小時。6.3.1手工測試度量(2)測試執(zhí)行摘要測試執(zhí)行摘要(TestExecutionSummary)給出測試用例執(zhí)行結(jié)果分類方面的狀態(tài)及原因,針對各類測試用例,給出了發(fā)布版本的靜態(tài)視圖,并收集執(zhí)行結(jié)果及測試用例數(shù)量的數(shù)據(jù)。測試執(zhí)行摘要如圖所示:摘要趨勢:人們也可以為各種不能進行的測試以及失敗的測試用例的原因進行分類以展示同樣的趨勢。6.3.1手工測試度量(3)軟件缺陷可接受率

軟件缺陷可接受率(DefectAcceptance,CA)決定測試組在執(zhí)行期間定義的有效軟件缺陷的數(shù)量,其計算公式如下:軟件缺陷可接受率=有效軟件缺陷數(shù)×100%總軟件缺陷數(shù)度量值可以和以前發(fā)布版本對比分析,如圖所示軟件缺陷可接受趨勢6.3.1手工測試度量(4)軟件缺陷不接受率軟件缺陷不接受率(DefectRejection,DR)決定在測試期間不接受的軟件缺陷數(shù)量,其計算公式如下:它提供了測試組已經(jīng)打開的無效軟件缺陷的百分比,如圖所示。軟件缺陷不接受趨勢軟件缺陷不接受率=軟件缺陷不接受數(shù)×100%總軟件缺陷數(shù)6.3.1手工測試度量(5)不良軟件缺陷修復(fù)率不良軟件缺陷修復(fù)率(BadFixDefect)是指由解決缺陷導(dǎo)致的新軟件缺陷。這項度量決定軟件缺陷修復(fù)過程的效果,其計算公式如下:它指出了需要控制的不良軟件缺陷修復(fù)的百分比,如圖所示。不良軟件缺陷修復(fù)趨勢不良軟件缺陷修復(fù)率=不良軟件缺陷修復(fù)數(shù)×100%總有效軟件缺陷數(shù)6.3.1手工測試度量(6)測試執(zhí)行生產(chǎn)率進一步分析測試執(zhí)行生產(chǎn)率(TestExcuationProductivity,TEP)可以得出確切的結(jié)果,TEP的計算公式如下:測試執(zhí)行生產(chǎn)率=測試用例執(zhí)行數(shù)×8(單位:執(zhí)行次數(shù)/天)

執(zhí)行時間(小時)測試執(zhí)行數(shù)(NumberofTestCaseExcuted,TE)的計算方法如下:TE=BTC+T(0.33)×0.33+T(0.66)×0.66+T(1)×1,其中,BTC是指基本測試用例(BaseTestCase),即至少執(zhí)行了一次的測試用例的數(shù)量。T(1)=重新測試需執(zhí)行總TC步驟的71%至100%的TC數(shù)量T(0.66)=重新測試需執(zhí)行總TC步驟的41%至70%的TC數(shù)量T(0.33)=重新測試需執(zhí)行總TC步驟的1%至40%的TC數(shù)量6.3.1手工測試度量基本測試用例情況用戶

名稱基礎(chǔ)執(zhí)行

效果(hr)重復(fù)運行

情況1重復(fù)執(zhí)行

效率1(hr)重復(fù)運行

情況2重復(fù)執(zhí)行

效率2(hr)重復(fù)運行

情況3重復(fù)執(zhí)行

效率3(hr)XYZ_12T(0.66)1T(0.66)0.45T(1)2XYZ_21.3T(0.33)0.03T(1)2

XYZ_32.3T(1)1.2

XYZ_42T(1)2

XYZ_52.15

6.3.1手工測試度量基本測試用例統(tǒng)計基礎(chǔ)測試用例5T(1)4T(0.66)2T(0.33)1測試用例執(zhí)行時間TE19.7因此,可以得出Te=5+(1×4+2×0.66+1×0.33)=5+5.65=10.65,測試執(zhí)行生產(chǎn)率=10.65/19.7×8≈4.3(執(zhí)行次數(shù)/天)。6.3.1手工測試度量人們可以和以前發(fā)布版對比測試執(zhí)行生產(chǎn)率,從而得出有效結(jié)論,如下圖所示。6.3.1手工測試度量(7)測試效率測試效率(TestEfficiency,TE)決定測試組在提交軟件缺陷時的效率,其計算公式如下:測試效率=DT/(DT+DU)×100%DT為在測試期間定義的有效軟件缺陷數(shù),DU為應(yīng)用發(fā)布后由用戶定義的有效軟件缺陷數(shù)。換句話說就是,事后測試軟件缺陷,如圖所示。測試效率趨勢6.3.1手工測試度量(8)軟件缺陷嚴重度指數(shù)軟件缺陷嚴重度指數(shù)(DefectSeverityIndex,DSI)決定測試時和發(fā)布時的產(chǎn)品質(zhì)量?;谶@項度量,人們可以決定是否發(fā)布產(chǎn)品,即這項度量代表了產(chǎn)品質(zhì)量,其計算公式如下:軟件缺陷嚴重度指數(shù)

=∑(缺陷嚴重度指數(shù)×該缺陷嚴重度指數(shù)下的有效軟件缺陷數(shù)量)有效軟件缺陷總數(shù)可以將軟件缺陷嚴重程度分為以下兩個部分:①所有狀態(tài)軟件缺陷的嚴重度指數(shù):這項值提供了在測試中的產(chǎn)品質(zhì)量。②打開狀態(tài)軟件缺陷的嚴重度指數(shù):這項值給出發(fā)布時的產(chǎn)品質(zhì)量。

此時計算軟件缺陷嚴重程度,必須考慮僅僅是打開狀態(tài)的軟件缺陷。6.3.1手工測試度量DSI(打開狀態(tài))

=∑(缺陷嚴重度指數(shù)×該缺陷嚴重度指數(shù)下打開狀態(tài)的有效軟件缺陷數(shù)量)有效打開狀態(tài)的軟件缺陷總數(shù)如圖所示的是對于所有狀態(tài)的缺陷嚴重度指數(shù)為2.8的DSI6.3.1手工測試度量如圖所示的是對于打開狀態(tài)的缺陷嚴重度指數(shù)為3.0的DSI6.3.1手工測試度量①測試中的產(chǎn)品質(zhì)量,即所有狀態(tài)軟件缺陷的軟件缺陷嚴重度指數(shù)

=2.8(高嚴重程度)。②發(fā)布時的產(chǎn)品質(zhì)量,即打開狀態(tài)軟件缺陷的軟件缺陷嚴重度指數(shù)

=3.0(高嚴重程度)。

如圖所示的是對于打開狀態(tài)的缺陷嚴重度指數(shù)為3.0的DSI6.3.1手工測試度量軟件缺陷嚴重度指數(shù)如圖:6.3.2性能測試度量幾種性能測試度量如下。(1)性能腳本生產(chǎn)率性能腳本生產(chǎn)率(PerformanceScriptingProductivity,PSP)為性能測試腳本提供腳本生產(chǎn)率以及一段時間內(nèi)的趨勢,其計算公式如下:性能腳本生產(chǎn)率

=∑性能操作用時(小時)6.3.2性能測試度量性能腳本示例執(zhí)行的操作是:①點擊數(shù)量,即點擊刷新的數(shù)據(jù);②輸入?yún)?shù)的數(shù)量;③關(guān)聯(lián)參數(shù)數(shù)量。執(zhí)行性能計數(shù)

點擊數(shù)量10輸入?yún)?shù)數(shù)量5關(guān)聯(lián)參數(shù)數(shù)量5總執(zhí)行性能20腳本編寫用時=10小時,性能腳本生產(chǎn)率=20/10=2(操作/小時),如下圖:6.3.2性能測試度量(2)性能執(zhí)行摘要性能執(zhí)行摘要(PerformanceExecutionSummary)列出了針對性能測試的各種類型,由狀態(tài)(通過/失?。┛刂频臏y試數(shù)量。性能測試類型包括峰值測試、壓力測試、耐力測試、故障切換測試等,如圖所示。6.3.2性能測試度量(3)性能執(zhí)行數(shù)據(jù)—客戶端性能執(zhí)行數(shù)據(jù)—客戶端給出執(zhí)行性能測試時客戶端數(shù)據(jù)的詳細信息。這項度量的數(shù)據(jù)包括運行用戶數(shù)、響應(yīng)時間、每秒點擊率、吞吐量、每秒總事務(wù)數(shù)、第1個字節(jié)傳輸時間、每秒錯誤數(shù)。(4)性能執(zhí)行數(shù)據(jù)—服務(wù)器端性能執(zhí)行數(shù)據(jù)—服務(wù)器端給出執(zhí)行性能測試時服務(wù)器端數(shù)據(jù)的詳細信息。這項度量的數(shù)據(jù)包括CPU占用率、內(nèi)存占用率、堆內(nèi)存占用率、每秒數(shù)據(jù)庫連接數(shù)。6.3.2性能測試度量(5)性能測試效率性能測試效率(PerformanceTestEfficiency,PTE)決定了性能測試團隊滿足需求的質(zhì)量,如果需要,可以將其用作后續(xù)改進的輸入,其計算公式如下:性能測試效率=PT期間滿足的需求

×100%PT期間滿足的需求+pt退出后未滿足的需求PT為性能測試期間。該指標需要在性能測試期間及測試結(jié)束后收集數(shù)據(jù)點。

一些性能測試的需求如下:平均響應(yīng)時間、每秒事務(wù)數(shù)、可以處理預(yù)定義的最大用戶負載、服務(wù)器穩(wěn)定性。例如,考慮在性能測試期間需滿足上述需求。已知:性能測試期間的需求數(shù)=4;在產(chǎn)品中,平均響應(yīng)時間比期望值更好,在性能測試結(jié)束后沒有滿足需求=1;可知,PTE=4/(4+1)×100%=80%,即性能測試效率是80%。6.3.2性能測試度量(6)性能嚴重程度指數(shù)性能嚴重程度指數(shù)(PerformanceSeverityIndex,PSI)決定基于性能標準的產(chǎn)品質(zhì)量,性能標準可以決定下階段是否發(fā)布產(chǎn)品,即它代表性能方面測試的產(chǎn)品質(zhì)量。其計算公式如下:性能嚴重程度指數(shù)

=∑(嚴重指數(shù)×該嚴重級別未滿足的需求數(shù))未滿足需求總數(shù)6.3.2性能測試度量如果性能不滿足要求,則可以分配要求的嚴重性,以便根據(jù)性能來決定產(chǎn)品的發(fā)布。例如

考慮到平均響應(yīng)時間沒有滿足的重要需求,測試人員可以按照標準打開軟件缺陷嚴重程度。性能嚴重程度指數(shù)=(4×1)/1=4(嚴重),如圖所示。6.3.3自動化測試度量幾種自動化測試度量如下:(1)自動化腳本生產(chǎn)率自動化腳本生產(chǎn)率(AutomationScriptingProductivity,ASP)為基于已有的分析得出最有效結(jié)論的自動化測試腳本生產(chǎn)率,其計算公式如下:自動化腳本生產(chǎn)率=∑執(zhí)行操作(單位:操作/小時)用時(小時)自動化腳本示例執(zhí)行的操作如下。①點擊數(shù)量,即點擊刷新的數(shù)據(jù)。②輸入?yún)?shù)的數(shù)量。③增加的檢查點個數(shù)。

溫馨提示

  • 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)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論