軟件質量量化指標.pdf

《軟件質量量化指標.pdf》由會員上傳分享，免費在線閱讀，更多相關內容在工程資料-天天文庫。

1、______________________________________________________________________________________________________________軟件測試質量評估方法討論稿當前我們的軟件測試質量評估主要考慮測試設計、測試執(zhí)行兩個方面，在測試過程中加入檢查點進行監(jiān)督，避免項目后期對項目的進展產生影響。一、測試設計測試設計主要指測試用例，其衡量方法采用事后追溯法，通過所有的測試發(fā)現(xiàn)的缺陷來評估測試設計質量。測試用例效率度量表如下：測

2、試用缺陷有測試用例對無測試用例對測試用例缺陷覆No備注例總數(shù)總數(shù)應的缺陷數(shù)應的缺陷數(shù)蓋度11044035535/40=87.5%二、測試執(zhí)行?每輪測試缺陷探測效率分析在軟件完成一輪完整測試后、或者在某個版本的測試后發(fā)現(xiàn)bug曲線有異常抬高，需要對該輪所發(fā)現(xiàn)所有缺陷進行歷史版本追溯分析，主要有以下幾情況分類：No歷史版本是否存在該缺陷原因分析改進措施1存在測試方案未包含更新方案2測試用例未包含補充測試用例3測試未執(zhí)行加強測試4不存在新功能或功能升級產生的新問題5修復缺陷導致的新問題說明：1.對于1、2需

3、要進行相關文檔補充和更新，保證后續(xù)測試的全面性；2.對于3則屬于個人問題，保證后續(xù)測試中避免該問題的發(fā)生；3.對于4則屬于正?，F(xiàn)像；4.對于5，則看實際導致的問題的數(shù)量，及后續(xù)bug曲線的收斂程度來確認開發(fā)人員所提交測試版本的質量。?A/B角互測驗證1.其本質也是確認缺陷探測效率，但通過B角去實現(xiàn)。在項目的某個測試階段加入B角進行一輪全面或局部測試，通過其發(fā)現(xiàn)的問題來確定當前軟件的測試質量。由于項目真正測試過程中的測試思路和測試用例需要不斷更新，這樣才能保證測試的全面性，如果發(fā)現(xiàn)統(tǒng)計數(shù)據(jù)異常能及時調整

4、；2.在測試計劃中添加A/B角的定義及B角參與的階段；并在該階段的測試報告中體現(xiàn)；3.Alpha測試用戶為自然B角，對Alpha測試過程中所發(fā)現(xiàn)的問題均要進行分析。-可編輯修改-______________________________________________________________________________________________________________已完成需求用例測試覆蓋率達100%本階段是否完成一輪全面測試測試階段性軟件質量當前項目千行bug率是否符合歷

5、史經驗數(shù)據(jù)bug曲線的收斂狀態(tài)遺留bug數(shù)量及類別符合通過標準軟件質量量化需求用例測試覆蓋率達100%系統(tǒng)測試是否完成一輪完整測試待發(fā)布軟件項目千行bug率是否符合歷史經驗數(shù)據(jù)bug曲線在最后系統(tǒng)測試階段完全收斂Alpha用戶測試發(fā)現(xiàn)問題的嚴重度(

6、?，F(xiàn)在有些公司流行每千行bug數(shù)的標準來制定測試計劃，這個標準是通過以往測試經驗總結出來的，一般來說，同類的產品，尤其是同一個開發(fā)流程的產品，這些數(shù)值不應該相差太多，如果相差一個數(shù)量級以上，我們幾乎可以說，要么是QA出問題了，要么是開發(fā)出問題了。2測試bug分級使用bugzilla或者Jira之類的缺陷管理系統(tǒng)何以很容易的實現(xiàn)bug分級，一般至少有Fatal,Major,Minor,cosmatic這幾種，還有一種特殊的叫做blocker，意思是這個bug會影響測試進度。產品發(fā)布前，可以根據(jù)實際情況，

7、定一個界限級別，比如要求新出Major為0，并且所有已有的Major全部close。3測試bug收斂量化評估必不可少的是bug收斂，這個要通過統(tǒng)計每日新出bug并跟蹤已有bug制作收斂曲線來實現(xiàn)。收斂曲線的形狀發(fā)散表明目前產品極其不穩(wěn)定，收斂曲線開始收斂表示目前產品趨于穩(wěn)定，完全收斂之后可以認為是發(fā)布的時機。4測試bug分布bug分布是決定下面測試重點的一個重要的參考數(shù)據(jù)。首先還是需要統(tǒng)計，找出所有已有的不同級別的bug在各個模塊的分布，假如ABC三個模塊，A模塊占了bug的60%，C模塊占了bug的

8、8%那么，我們可以得出這樣的結論，軟件的不穩(wěn)定瓶頸在于A模塊，是一個薄弱點，需要開發(fā)人員集中力量對應。但是C模塊也是一個可疑模塊，因為出現(xiàn)bug率太低，如果不是開發(fā)的太好就是測試方法不當。5測試bug的周期一個bug的生命歷程是一個完整的輪回，從他出生(open)開始，到調查(Accept)到修復(Fix)，再到確認(Verify)是最簡單的路線，這個周期越短，說明項目進展越順利反之則意味著項目進度目前有很大的阻礙。6降級bug數(shù)-可編輯修改-_____