基于測試流程上的缺陷管理系統(tǒng)(存儲版)
【正文】 簡單 一個 bug一個報告 ?可以提出對錯誤的解決建議 ?開發(fā)人員拒絕修改的 bug ?程序員無法重現(xiàn)或者現(xiàn)象難以捕捉 ?沒有明確的報告以說明重現(xiàn) bug的步驟 ?程序員無法讀懂的 bug報告 ?用戶很少使用或者不符合用戶使用習(xí)慣的操作出錯 ?由不受信任的測試人員提出 缺陷報告 Founder RD 集成測試缺陷處理流程 退回 Founder RD 缺陷分析的關(guān)注點： 對軟件問題的功能域分布進(jìn)行分析 ， 找出系統(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)件 ） 中 。 Founder RD 測試人員的績效評價 ? 評價標(biāo)準(zhǔn)： ? bug數(shù)量： ? 同一個項目組內(nèi)，提交 bug數(shù)量的多少是衡量測試人員工作效率的一方面；另一個衡量指標(biāo)是每人日提交的 bug數(shù)。 ? 在計算缺陷密度時，最重要的是要使用正確的規(guī)模測量。 7. 測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目（即檢錯率）很可能成正比； (編碼規(guī)范、需求理解、技術(shù)能力、內(nèi)部耦合性是引起這些現(xiàn)象的原因 ) 8. 程序中的大部分錯誤往往是在一小部分模塊中發(fā)現(xiàn)的，遵循普遍適用的“二八定理”（即 80%的錯誤往往是由 20%的模塊所造成的），例如， IBM公司的 OS/370操作系統(tǒng)中， 47% 的錯誤僅與該系統(tǒng)中的 4%的程序模塊有關(guān)； 9. 要嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性，這樣才能消除各種無序操作所造成的副作用； 測試設(shè)計決定了測試的有效性和效率，測試工具只能提高測試效率 10. 應(yīng)當(dāng)對每一個測試結(jié)果做全面的檢查，這樣才有可能找到真正的出錯原因，為今后的調(diào)試工作奠定基礎(chǔ)。
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1