基于測試流程上的缺陷管理系統(tǒng)_第1頁
基于測試流程上的缺陷管理系統(tǒng)_第2頁
基于測試流程上的缺陷管理系統(tǒng)_第3頁
基于測試流程上的缺陷管理系統(tǒng)_第4頁
基于測試流程上的缺陷管理系統(tǒng)_第5頁
已閱讀5頁,還剩17頁未讀 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

三、基于測試流程上的缺陷管理系統(tǒng)缺陷的定義軟件沒有達到產(chǎn)品說明書表明的功能軟件出現(xiàn)了產(chǎn)品說明書中不一致的表現(xiàn)軟件功能超出產(chǎn)品說明書的范圍軟件沒有達到用戶期望的目標(biāo)(雖然產(chǎn)品說明書中沒有要求)測試員或用戶認(rèn)為軟件的易用性差不是所有缺陷都會修改市場的壓力使得產(chǎn)品最終發(fā)行有時間限制測試員錯誤理解或者不正確操作引出的缺陷(FAQ)錯誤的修改影響的模塊較多,帶來的風(fēng)險較大(遺留)修改性價比太低(FAQ,遺留)缺陷報告中提出的問題很難重現(xiàn)FounderR&D3.1缺陷報告管理系統(tǒng)是測試流程在工具上的固化通過權(quán)限控制來實現(xiàn)流程監(jiān)控記錄了缺陷識別到關(guān)閉過程中的所有數(shù)記錄了版本變更的信息是開發(fā)和測試之間溝通的信息平臺實時的數(shù)據(jù)和信息的更新度量和統(tǒng)計分析,為改進產(chǎn)品提供依據(jù)FounderR&DFounderR&D采用LotusNotes作為bug管理平臺完全電子化的信息傳遞統(tǒng)一管理和備份具備數(shù)據(jù)統(tǒng)計和查詢功能能夠進行個性化二次開發(fā)方正測試缺陷跟蹤與管理系統(tǒng)3.1.1系統(tǒng)測試缺陷處理流程新建表單待測試提交待指定處理人正在處理返回處理待開發(fā)提交待返測待歸檔已歸檔個人提交退回測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回提交版本更新說明FounderR&DBug報告準(zhǔn)則如何重現(xiàn)錯誤-使用最少步驟重現(xiàn)現(xiàn)象描述沒有歧義盡量簡單-一個bug一個報告可以提出對錯誤的解決建議開發(fā)人員拒絕修改的bug程序員無法重現(xiàn)或者現(xiàn)象難以捕捉?jīng)]有明確的報告以說明重現(xiàn)bug的步驟程序員無法讀懂的bug報告用戶很少使用或者不符合用戶使用習(xí)慣的操作出錯由不受信任的測試人員提出缺陷報告FounderR&D3.1.2集成測試缺陷處理流程新建表單待指定處理人正在處理待返測待歸檔已歸檔返回處理測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回FounderR&D4.1缺陷分析的關(guān)注點:1、對軟件問題的功能域分布進行分析,找出系統(tǒng)的薄弱環(huán)節(jié)要詳細(xì)采集每個功能模塊或系統(tǒng)構(gòu)件的bug數(shù)據(jù),并按功能、錯誤類型、嚴(yán)重程度等分類比較實際發(fā)現(xiàn)的軟件bug是否與預(yù)期的問題分布相吻合二八定理:80%的軟件問題總是發(fā)生在大約20%的功能模塊(系統(tǒng)構(gòu)件)中。FounderR&D缺陷分析的關(guān)注點2、對bug的注入階段的分布進行分析,并與歷史數(shù)據(jù)相比較。應(yīng)按不同的開發(fā)階段詳細(xì)采集bug的數(shù)據(jù)要求軟件各開發(fā)階段的缺陷密度小于本單位過去的平均值而且要求需求分析、設(shè)計和代碼復(fù)查階段的缺陷排除率之和大于或等于規(guī)定值(例如75%)。(同行評審)FounderR&DFounderR&D缺陷分析的關(guān)注點3、應(yīng)對軟件缺陷類型進行分析,以便針對各自的特點,先修復(fù)嚴(yán)重缺陷。可參考PSP中缺陷類型標(biāo)準(zhǔn)(如下表),其中缺陷類型是按照問題的復(fù)雜度來排列的,類型10到40是比較簡單的編碼缺陷,類型50到100是比較復(fù)雜的設(shè)計缺陷。類型編號類型名稱描述10文檔注釋,消息20句法拼寫,標(biāo)點,打字,指令格式30聯(lián)編,打包理改管理,庫,版本控制40分配說明,重名,作用域,限制50接口過程調(diào)用和引用,輸入/輸出,用戶格式60檢查出錯信息,不恰當(dāng)?shù)臋z查70數(shù)據(jù)結(jié)構(gòu),內(nèi)容80函數(shù)邏輯,指針,循環(huán),遞歸,計算,函數(shù)缺陷90系統(tǒng)配置,記時,內(nèi)存100環(huán)境設(shè)計,編譯,測試,或其它支持系統(tǒng)問題缺陷分析的關(guān)注點4、應(yīng)動態(tài)采集每個測試周期中發(fā)現(xiàn)的bug數(shù),并有效地控制缺陷的修復(fù)率。5、應(yīng)密切觀察bug的狀態(tài),并及時跟蹤其狀態(tài)的變化,以檢查測試和開發(fā)人員的工作情況FounderR&D缺陷分析的的關(guān)注點6、應(yīng)該采采集bug不同方式式的修復(fù)數(shù)數(shù)據(jù),以便便檢驗軟件件產(chǎn)品是否否滿足交付付規(guī)則分析修改代代碼、改變變設(shè)計、封封掉功能遺遺留以及下下一版本解解決的bug數(shù)約占占缺陷總數(shù)數(shù)的比例。。在有嚴(yán)密和和有效的質(zhì)質(zhì)量保證體體系條件的的監(jiān)控下,,常常會引引起有較高高比例的延延期解決的的缺陷數(shù),,這是因為為許多細(xì)微微的或枝節(jié)節(jié)性的問題題被測試出出來,經(jīng)過過評價證明明不會造成成大的質(zhì)量量影響,但但可為產(chǎn)品品進一步升升級提供有有價值的參參考。FounderR&D4.2測測試人員的的績效評價價評價標(biāo)準(zhǔn)::1、bug數(shù)量:同一個項目目組內(nèi),提提交bug數(shù)量的多多少是衡量量測試人員員工作效率率的一方面面;另一個個衡量指標(biāo)標(biāo)是每人日日提交的bug數(shù)。。2、bug嚴(yán)重程度度:Bug的嚴(yán)嚴(yán)重程度是是衡量bug的質(zhì)量量的一個重重要因素,,好的bug應(yīng)該是是極端嚴(yán)重重的,對系系統(tǒng)造成極極大危害的的。3、bug價值:Bug的雙雙方面評判判,對于bug的價價值開發(fā)人人員在另外外一個角度度上進行評評判以上三個因因素的加權(quán)權(quán)平均才能能更有效的的評價測試試人員的績績效!FounderR&D4.3缺缺陷統(tǒng)計分分析工具介介紹FounderR&D測試結(jié)果分分析和評價價缺陷密度:基本的缺陷陷測量是以以每千行代代碼的缺陷陷數(shù)(Defects/KLOC)來來測量的。。稱為缺陷陷密度(Dd),其其測量單位位是defects/KLOC??砂窗凑找韵虏讲襟E來計算算一個程序序的缺陷密密度:累計開發(fā)過過程中每個個階段發(fā)現(xiàn)現(xiàn)的缺陷總總數(shù)(D)。統(tǒng)計程序中中新開發(fā)的的和修改的的代碼行數(shù)數(shù)(N)。。計算每千行行的缺陷數(shù)數(shù)Dd=1000*D/N。。例如,一個個29.6萬行的源源程序總共共有145個缺陷,,則缺陷密密度是:Dd=1000*145/296000=0.49defects/KLOC。。在計算缺陷陷密度時,,最重要的的是要使用用正確的規(guī)規(guī)模測量。。FounderR&D測試結(jié)果的的分析和評評價輸出《測試試綜合報告告》:測試過程的的總結(jié)測試數(shù)據(jù)分分析(按照照嚴(yán)重程度度等方式分分類統(tǒng)計的的分析,包包括測試密密度等)產(chǎn)品主要問問題和總體體評價遺留的問題題總結(jié)最終的測試試結(jié)論FounderR&D測試結(jié)果分分析和評價價為了了解和和控制缺陷陷帶來的費費用,很有有必要測量量缺陷排除除的效果測測量:一種測量方方法是計算算每小時排排除缺陷的的個數(shù);一種是計算算缺陷排除除效益,即即測量通過過某一排除除方法所發(fā)發(fā)現(xiàn)的缺陷陷的百分比比。缺陷排除效效益是45%100個缺缺陷開始測試測試發(fā)現(xiàn)45個個缺陷missing55defectsFounderR&D測試結(jié)果分分析和評價價測試覆蓋率率測量語句覆蓋率率 測試試經(jīng)歷語句句數(shù)/總語語句數(shù)分支覆蓋率率 測試試經(jīng)歷支路路數(shù)/總支支路數(shù)簡單路徑覆覆蓋率測測試經(jīng)歷簡簡單路徑數(shù)數(shù)/總簡單單路徑數(shù)功能覆蓋率率界面數(shù)菜單數(shù)輸入/輸出出的數(shù)據(jù)元元數(shù)構(gòu)件、模塊塊…FounderR&D4.5軟件件測試經(jīng)驗驗分享所有的測試試都應(yīng)追溯溯到需求。。因最嚴(yán)重重的錯誤是是導(dǎo)致程序序無發(fā)滿足足需求的錯錯誤;軟件開發(fā)人人員和管理理人員首先先應(yīng)該盡早早地和不斷斷地進行各各種軟件質(zhì)質(zhì)量保證活活動(如需需求和設(shè)計計階段同行行評審和走走查等);軟件開發(fā)人人員應(yīng)避免免檢查自已已的程序,,利用同行行評審的方方式對代碼碼進行審查查;(自己檢查容容易依照原原有的程序序設(shè)計思路路進行,往往往查不出出問題)在設(shè)計測試試用例時,,必須明確預(yù)預(yù)期的輸出出結(jié)果,否否則對實際際的輸出結(jié)結(jié)果很難有有檢驗的標(biāo)標(biāo)準(zhǔn),測試試失去意義義。測試用例應(yīng)應(yīng)由輸入數(shù)數(shù)據(jù)和與之之對應(yīng)的期期望輸出結(jié)結(jié)果這兩部部分組成,,在輸入數(shù)數(shù)據(jù)中,應(yīng)應(yīng)當(dāng)包括合合理的輸入入條件和不不合理的輸輸入條件;;在進行各種種分析和修修復(fù)工作中中,要充分分注意修復(fù)復(fù)工作所產(chǎn)產(chǎn)生的影響響效果和波波及效果。。FounderR&D軟件測試經(jīng)經(jīng)驗分享統(tǒng)計表明大大約有60%的錯誤誤是在設(shè)計計階段之前前注入的,,并且修正正一個軟件件錯誤所需需的費用將將隨著軟件件生存期的的進展而上上升。錯誤誤發(fā)現(xiàn)得越越晚,修復(fù)復(fù)它的費用用就越高,,而且呈指指數(shù)增長的的趨勢。測試后程序序中殘存的的錯誤數(shù)目目與該程序序中已發(fā)現(xiàn)現(xiàn)的錯誤數(shù)數(shù)目(即檢檢錯率)很很可能成正正比;(編碼規(guī)范、、需求理解解、技術(shù)能能力、內(nèi)部部耦合性是是引起這些些現(xiàn)象的原原因)程序中的大大部分錯誤誤往往是在在一小部分分模塊中發(fā)發(fā)現(xiàn)的,遵遵循普遍適適用的“二二八定理””(即80%的錯誤誤往往是由由20%的的模塊所造造成的),,例如,IBM公司司的OS/370操操作系統(tǒng)中中,47%的錯誤誤僅與該系系統(tǒng)中的4%的程序序模塊有關(guān)關(guān);要嚴(yán)格執(zhí)行行測試計劃劃,排除測測試的隨意意性,這樣樣才能消除除各種無序序操作所造造成的副作作用;測試設(shè)計決決定了測試試的有效性性和效率,,測試工具具只能提高高測試效率率應(yīng)當(dāng)對每一一個測試結(jié)結(jié)果做全面面的檢查,,這樣才有有可能找到到真正的出出錯原因,,為今后的的調(diào)試工作作奠定基礎(chǔ)礎(chǔ)。FounderR&D結(jié)束語產(chǎn)品越復(fù)雜雜,測試花花費的時間間就越長,,費用就越越大,測試試發(fā)現(xiàn)缺陷陷的效率也也就越低。。缺陷會掩蓋蓋或加重其其它缺陷。。也就是說說,當(dāng)一個個程序有許許多缺陷時時,由于缺缺陷相互作作用,使得得發(fā)現(xiàn)和修修復(fù)缺陷的的過程更加加復(fù)雜。這這使得一些些缺陷很難難查找和修修復(fù)。一個個缺陷可能能掩蓋其它它缺陷,使使得這些被被掩蓋的缺缺陷難以發(fā)發(fā)現(xiàn),增加加了它們

溫馨提示

  • 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

提交評論