【正文】 項目不同而變化。這主要根據(jù)開發(fā)和測試項目的類型，開發(fā)和用戶環(huán)境，以及其他質(zhì)量和商業(yè)需求不同決定。3. 風(fēng)險評估：確定潛在的發(fā)現(xiàn)在系統(tǒng)功能和特征上的影響。包括失敗的可能性以及失敗后對每個功能產(chǎn)生的不利后果。4. 風(fēng)險減輕：基于上面的一些行為，減輕和避免風(fēng)險或者減少風(fēng)險產(chǎn)生的影響。將測試關(guān)注在關(guān)鍵性的功能上是減少風(fēng)險的一個有效方法。5. 風(fēng)險報告：傳統(tǒng)的報告信息包括錯誤數(shù)目，每個功能對應(yīng)的錯誤，錯誤的分類，每個錯誤測試花的時間等。6. 風(fēng)險預(yù)測：根據(jù)先前已經(jīng)確定的風(fēng)險的歷史和信息預(yù)測當(dāng)前風(fēng)險.。 風(fēng)險分析活動模式 一個實用的風(fēng)險模型風(fēng)險因為項目的不同而變化。也可能在同一個項目中因為優(yōu)先級和開發(fā)的策略的變化而變化。在面向?qū)ο箜椖恐校L(fēng)險都是同項目的架構(gòu)特征，對象間復(fù)雜的交互，類的復(fù)雜行為和項目需求的變化相關(guān)的。我們的研究是基于需求規(guī)范說明的。我們不考慮風(fēng)險和代碼之間的關(guān)系。Amland引入了專用名詞：風(fēng)險敞口(Risk Exposure) [23]，介紹了一種簡單的風(fēng)險模型，這種風(fēng)險模型僅僅需要兩個風(fēng)險敞口的要素。我們在研究中使用這個模式?？聪旅妫?. 缺陷出現(xiàn)的可能性。Myers 說[18]：隨著被發(fā)現(xiàn)的錯誤數(shù)量增加，沒被發(fā)現(xiàn)的錯誤數(shù)量也可能增加。因為每個錯誤都可能導(dǎo)致更多的錯誤。因此，在基線測試階段哪個組件出現(xiàn)的錯誤越多，在回顧測試階段這個組件的測試要越仔細。2. 缺陷的成本(后果或影響)大家都知道，大部分商業(yè)軟件在發(fā)布時都或多或少存在Bug。公司會因為開發(fā)壓力，時間問題等不得不留下一些Bug。許多缺陷會產(chǎn)生很嚴重的后果。在我們的定義中，成本就是缺陷產(chǎn)生的后果或影響。缺陷產(chǎn)生的影響越大，這個缺陷的級別越高。為了在有限的成本和時間內(nèi)減低風(fēng)險，我們努力最先發(fā)現(xiàn)和修復(fù)最致命的缺陷?？傊?，我們最關(guān)注最高成本的缺陷。計算風(fēng)險敞口的公式： REf = Pf Cf (41)REf 是功能f的風(fēng)險敞口；Pf是缺陷f發(fā)生的可能性；Cf是缺陷f的成本 本章小結(jié)在這章中，我們提供了關(guān)于基于風(fēng)險分析和測試的背景知識。同時我們討論了風(fēng)險測試的具體過程。最后，我們介紹了一個簡單的風(fēng)險模型，還提供了一個風(fēng)險敞口計算公式。這個風(fēng)險模型和公式會在我們的研究中用到。42浙江大學(xué)碩士學(xué)位論文 第5章方法2：基于風(fēng)險的回歸測試第5章 方法2：基于風(fēng)險的回歸測試 引言在前面中我們講了基于活動圖的回歸測試選擇技術(shù)。但是在回歸測試中僅僅一個測試用例選擇策略是不夠的，所以我們要一些其他的策略來共同進行回歸測試，以增加對軟件質(zhì)量的信心。在這章中，我們提供了基于風(fēng)險的回歸測試選擇技術(shù)，是基于活動圖的回歸測試選擇技術(shù)有益的補充。 基于風(fēng)險的回歸測試方法第3章中，我們講了基于活動圖的回歸測試選擇技術(shù)。因為基于活動圖的回歸測試選擇技術(shù)是基于需求規(guī)范說明的，許多因為程序代碼變化而發(fā)生地錯誤很可能會被忽略。有兩個主要的原因?qū)е逻@種忽略。1. 復(fù)雜性：當(dāng)前的軟件系統(tǒng)的組件之間的關(guān)系是非常復(fù)雜的，我們很難準確地去抓取它們。一旦代碼發(fā)生改變，開發(fā)人員很難確定發(fā)生變化的所有組件，尤其是變化發(fā)生在一些一般的功能上。例如，一個處理字符串的功能塊發(fā)生變化時，對輸入/輸出功能會發(fā)生很大影響。2. 不完全或廢棄的文檔：文檔是基于規(guī)范說明的測試的基礎(chǔ)。為了正確地進行基于活動圖的測試用例選擇，我們必須有記錄所有糾正性維護和改進性維護的完整，正確的文檔。這對于統(tǒng)計受影響的實體很重要?？墒牵聦嵣?，很普遍的情況是：很多文檔是不完全或者是過時的。如果一個開發(fā)人員改變代碼而沒有作一個記錄，而這個變化也沒在測試文檔中體現(xiàn)出來，那么測試人員很可能會忽略這些可能會發(fā)生錯誤的地方。為了確保軟件的質(zhì)量和提升我們測試的信心，我們想要將除了目標性測試用例以外的測試用例加入到測試用例集中。Rotherme將回歸測試分成兩個階段：初步階段和臨界階段。初步階段開始于軟件某個版本的release。在軟件開發(fā)中，開發(fā)如果是基于增量模式的，開發(fā)每一個增量都屬于這個階段。在初步階段，開發(fā)人員依然在提升和糾正軟件。當(dāng)?shù)谝浑A段完成后，開始臨界階段。在這個階段，基于風(fēng)險的測試很有用：1. 在執(zhí)行完目標性測試后，如果時間和資源還有剩余，測試人員可能會希望執(zhí)行目標性測試以外的測試用例，以增加改變后的系統(tǒng)的信心。2. 軟件發(fā)布的時間可能很緊，可能會沒什么時間去做臨界階段的測試，因為往往大部分時間都花在初步階段的測試上。基于風(fēng)險的測試提供這樣一個保證：確保這個release上留下的錯誤不會導(dǎo)致嚴重的問題。在上面兩種情況下，基于風(fēng)險的測試是一個好的選擇。在臨界階段，因為是產(chǎn)品release的最后期限，所以時間是有限的。因此，高效地使用時間和資源是非常重要的。一個有效，高效的回歸測試技術(shù)在臨界階段是很重要的?；陲L(fēng)險的測試關(guān)注的是關(guān)鍵的功能。一個組件越重要，優(yōu)先級的級別越高。在基于風(fēng)險的測試中，沒測試過的組件被判定為比那些已經(jīng)測試過的組件有更低的優(yōu)先級。在有限的時間里，我們使用風(fēng)險覆蓋率去選擇測試用例，以達到更高的信心。因此，我們建議用基于風(fēng)險的方法來選擇測試用例。 基于風(fēng)險的回歸測試用例選擇技術(shù)在這節(jié)中，我們提供了基于風(fēng)險的回歸測試用例選擇的方法。選擇測試用例的要求是達到最高的風(fēng)險覆蓋率。我們的方法是使用第3章中用來進行風(fēng)險分析的風(fēng)險模型。在這個模型中，風(fēng)險是風(fēng)險敞口(RE)來確定數(shù)量和計量的。首先，我們計算每個測試用例的風(fēng)險敞口(REt)，下標表示測試用例。接著，我們?yōu)榘踩詼y試用例集選擇最高級別的REt。有4個步驟： 第1步. 為每個測試用例評估相對應(yīng)的潛在的錯誤的成本Ct 第2步. 獲取每個測試用例的可能性嚴重性Pt 第3步. 為每個測試用例計算風(fēng)險敞口REt 第4步. 選擇REt值高的測試用例作為測試用例 評估測試用例相對應(yīng)的潛在的錯誤的成本(第1步)在風(fēng)險模型中，成本是被定義為錯誤的影響或結(jié)果。我們相信成本是和錯誤發(fā)生地功能聯(lián)系在一起的。功能越重要，這個功能中錯誤的成本越高。一個系統(tǒng)功能可能包含幾個需求特征。在論文中，我們使用“缺陷的成本”表示因為缺陷引起的錯誤導(dǎo)致的成本。為了使成本的評估更為合理，兩種成本應(yīng)該考慮到：1. 客戶眼中的錯誤成本：CC。比如，因為軟件的錯誤，失去市場份額，沒有履行政府規(guī)定等等。2. 供應(yīng)商眼中的錯誤成本：CV。比如，因為軟件的錯誤，導(dǎo)致高額的軟件維護費用，對名聲和市場占有率的影響等等。在我們的研究中，我們并不確定哪類成本更加重要。但是，在我們的方法中我們使用平均成本C來表示軟件系統(tǒng)中的成本。公式如下: C = (CC + CV)/2 （51）在上一章中，我們描述了怎么樣跟蹤測試用例和活動圖間的聯(lián)系。因為活動圖的元素node 和 edge都映射到需求特征，我們可以明白測試用例和需求特征間的聯(lián)系。因此，我們可以聯(lián)系需求特征的錯誤成本和測試用例的錯誤成本。在本文中，我們定義測試用例的錯誤成本Ct作為用這個測試用例測試的需求特征的成本。因此，我們得到下面的公式：Ct = (CCt +CVt)/2 （52）當(dāng)然，CCt 和CVt都要給出一定的值用來計算Ct。我們用從1到5的標度來表示CCt 和CVt的值。 客戶缺陷成本當(dāng)測試人員測試一個軟件系統(tǒng)時，他們應(yīng)該模擬客戶的操作行為來運行系統(tǒng)。因此，測試人員要理解客戶是怎么使用系統(tǒng)的。根據(jù)他們的經(jīng)驗和關(guān)于客戶的知識，測試人員經(jīng)?？梢栽u估出CCt。根據(jù)活動圖，每個測試用例都表示一個控制流，包含一些特定的數(shù)據(jù)。為了評估測試用例的CCt的值，我們?yōu)闇y試人員建立了一個調(diào)查表，調(diào)查表里有一些與控制流和數(shù)據(jù)相關(guān)的問題。舉個例子：1. 測試用例是否測試新的系統(tǒng)特征？2. 測試用例是否測試改變后的系統(tǒng)特征？3. 客戶使用這些系統(tǒng)特征的頻率是多少？如果一個測試用例可以測試幾個特征，通常情況是這個測試用例只是針對這些特征內(nèi)的某個特征。對于調(diào)查表中的每個問題，我們會提供多個選項。上面3個問題的選項如下：1. 測試用例是否測試新的系統(tǒng)特征？Yes – 2分 No – 0分2. 測試用例是否測試改變后的系統(tǒng)特征？Yes – 2分 No – 0分3. 客戶使用這些特征的頻率是多少？很頻繁 –2分 頻繁 – 1分 很少 – 0分當(dāng)回答這些問題時，測試人員會根據(jù)這些問題的分數(shù)給測試用例打分。例如，對于測試用例t0010來說，如果測試人員對問題1選擇了“Yes”，問題2選擇了“No”。問題3選擇了“很頻繁”。那么測試用例t0010就從問題1得到2分，問題2得到0分，問題3得到2分。當(dāng)測試人員對所有的測試用例都回答了問題，他們對每個測試用例計算總的分數(shù)，就是計算對應(yīng)的每個測試用例回答問題的分數(shù)。在我們的例子里，測試用例t0010的總分是17?？幢?1所列。一旦所有的測試用例的分數(shù)被列在表格中，我們用這個方法來評估CCt：1. 對于分數(shù)排在前20%的測試用例：CCt = 52. 對于分數(shù)排在前20%~40%的測試用例：CCt = 43. 對于分數(shù)排在前40%~60%的測試用例：CCt = 34. 對于分數(shù)排在前60%~80%的測試用例：CCt = 25. 對于分數(shù)排在最后20%的測試用例：CCt = 1表51：一些測試用例的CCTest CaseQ1Q2Q3…TotalCCtt0010202…175t0020022…83t0030202…62t0040021…124t0050001…31t0060200…52t0070001…31………………………看圖51，上面已經(jīng)計算好結(jié)果了。比如測試用例t0010分數(shù)是17，屬于分數(shù)是前20%的，CCt = 5不同的公司有不同的測試關(guān)注點，同一個公司在測試的不同階段也有不同的關(guān)注點。因此，調(diào)查表有基于公司的，基于階段的，基于組件的。一個調(diào)查表包含許多一般的問題。我們稱之為基本調(diào)查表。在我們的研究中，測試人員在基本調(diào)查表的基礎(chǔ)上根據(jù)系統(tǒng)功能和測試目的的不同增加新的問題。 供應(yīng)商缺陷成本對于產(chǎn)品提供商來說，維護成本是缺陷成本中最主要的部分。在我們的研究中，越復(fù)雜的系統(tǒng)，維護成本越高。因此，我們通過評估系統(tǒng)的復(fù)雜性來計量CVt的值。我們前面提過，測試用例包括特定的控制流和特定的測試數(shù)據(jù)。顯而易見的，控制流的復(fù)雜程度直接影響測試用例的復(fù)雜程度。例如，在電子商務(wù)網(wǎng)站中，一個支付過程有幾個支付方法。因為某些支付方法比其他的支付方法都要復(fù)雜得多，所以測試這些支付方法的測試用例也復(fù)雜得多。因此，我們要在這種復(fù)雜的計量中考慮控制流和測試數(shù)據(jù)兩者的復(fù)雜性。在本文中我們使用CompCFt表示控制流的復(fù)雜度，CompDt表示測試數(shù)據(jù)的復(fù)雜度，Compt表示測試用例的復(fù)雜度。計算測試用例復(fù)雜度的公式如下圖： Compt = CompCFt CompDt (53) 因為開發(fā)人員很熟悉控制流，所以我們把復(fù)雜的調(diào)查表給開發(fā)人員填寫，從而獲取我們系統(tǒng)的大致復(fù)雜度。當(dāng)測試人員已經(jīng)完成他們的測試計劃，開發(fā)人員就會被要求評估控制流和測試數(shù)據(jù)的復(fù)雜度，給每個測試用例評分數(shù)：1~5。1代表最簡單的，5代表最復(fù)雜的。這些評估都是用調(diào)查表的形式完成的。在本文中，我們用公式Compt = CompCFt CompDt 計算復(fù)雜度。我們建立了兩個調(diào)查表，一個評估控制流的復(fù)雜度CompCFt ，另一個評估測試數(shù)據(jù)的復(fù)雜度CompDt。下面列舉了些在調(diào)查表中的簡單的問題：對于CompCFt ：1. 包含多少行代碼？2. 是不是使用了很多控件？3. 是不是直接前進的代碼(很少用到需要判斷的if – then – else 語句)?對于CompDt ：4. 測試數(shù)據(jù)是不是需要額外的處理？同前面的調(diào)查表一樣，對應(yīng)每一個問題，都有多個選項，對應(yīng)分數(shù)。如下所示：5. 包含多少行代碼？＞1000 – 2分 300 ~ 1000 – 1分 ＜300 – 0分6. 是不是使用了很多控件？許多– 2分 一些 – 1分 很少 – 0分7. 是不是直接前進的代碼(很少用到需要判斷的if – then – else 語句)?No – 2分 some – 1分 Yes – 0分8. 測試數(shù)據(jù)是不是需要額外的處理？Yes – 2分 No – 0分 上面僅僅是一些例子，開發(fā)人員可以增加問題到他們的調(diào)查表中。我們評估復(fù)雜度：1. 對于分數(shù)排在前20%的測試用例：CVt = 52. 對于分數(shù)排在前20%~40%的測試用例：CVt = 43. 對于分數(shù)排在前40%~60%的測試用例：CVt = 34. 對于分數(shù)排在前60%~80%的測試用例：CVt = 25. 對于分數(shù)排在最后20%的測試用例：CVt = 1表52，我們看到測試用例t0010的Compt值為12，分數(shù)排在前20%~40%，因此CVt = 4。表52：測試用例的CV值Test CaseCompCFtCompDt(d)Compt = CompCFtCompDt (d)CVtt001034124t002053155t003025104t00402121t00504283