缺陷處理流程課件

三、基于測試流程上的缺陷管理系統(tǒng)缺陷的定義軟件沒有達到產品說明書表明的功能軟件出現(xiàn)了產品說明書中不一致的表現(xiàn)軟件功能超出產品說明書的范圍軟件沒有達到用戶期望的目標(雖然產品說明書中沒有要求)測試員或用戶認為軟件的易用性差不是所有缺陷都會修改市場的壓力使得產品最終發(fā)行有時間限制測試員錯誤理解或者不正確操作引出的缺陷(FAQ)錯誤的修改影響的模塊較多，帶來的風險較大（遺留）修改性價比太低(FAQ，遺留）缺陷報告中提出的問題很難重現(xiàn)FounderR&D三、基于測試流程上的缺陷管理系統(tǒng)缺陷的定義FounderR13.1缺陷報告管理系統(tǒng)是測試流程在工具上的固化通過權限控制來實現(xiàn)流程監(jiān)控記錄了缺陷識別到關閉過程中的所有數記錄了版本變更的信息是開發(fā)和測試之間溝通的信息平臺實時的數據和信息的更新度量和統(tǒng)計分析，為改進產品提供依據FounderR&D3.1缺陷報告管理系統(tǒng)是測試流程在工具上的固化Founde2FounderR&D采用LotusNotes作為bug管理平臺完全電子化的信息傳遞統(tǒng)一管理和備份具備數據統(tǒng)計和查詢功能能夠進行個性化二次開發(fā)方正測試缺陷跟蹤與管理系統(tǒng)FounderR&D采用LotusNotes作為bug管33.1.1系統(tǒng)測試缺陷處理流程新建表單待測試提交待指定處理人正在處理返回處理待開發(fā)提交待返測待歸檔已歸檔個人提交退回測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回提交版本更新說明FounderR&D3.1.1系統(tǒng)測試缺陷處理流程新建表單待測試提交待指4Bug報告準則如何重現(xiàn)錯誤-使用最少步驟重現(xiàn)現(xiàn)象描述沒有歧義盡量簡單-一個bug一個報告可以提出對錯誤的解決建議開發(fā)人員拒絕修改的bug程序員無法重現(xiàn)或者現(xiàn)象難以捕捉沒有明確的報告以說明重現(xiàn)bug的步驟程序員無法讀懂的bug報告用戶很少使用或者不符合用戶使用習慣的操作出錯由不受信任的測試人員提出缺陷報告FounderR&D缺陷報告FounderR&D53.1.2集成測試缺陷處理流程新建表單待指定處理人正在處理待返測待歸檔已歸檔返回處理測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回FounderR&D3.1.2集成測試缺陷處理流程新建表單待指定處理人64.1缺陷分析的關注點：1、對軟件問題的功能域分布進行分析，找出系統(tǒng)的薄弱環(huán)節(jié)要詳細采集每個功能模塊或系統(tǒng)構件的bug數據，并按功能、錯誤類型、嚴重程度等分類比較實際發(fā)現(xiàn)的軟件bug是否與預期的問題分布相吻合二八定理：80%的軟件問題總是發(fā)生在大約20%的功能模塊（系統(tǒng)構件）中。FounderR&D4.1缺陷分析的關注點：1、對軟件問題的功能域分布進行分析7缺陷分析的關注點2、對bug的注入階段的分布進行分析，并與歷史數據相比較。應按不同的開發(fā)階段詳細采集bug的數據要求軟件各開發(fā)階段的缺陷密度小于本單位過去的平均值而且要求需求分析、設計和代碼復查階段的缺陷排除率之和大于或等于規(guī)定值（例如75%）。（同行評審）FounderR&D缺陷分析的關注點2、對bug的注入階段的分布進行分析，并與歷8FounderR&D缺陷分析的關注點3、應對軟件缺陷類型進行分析，以便針對各自的特點，先修復嚴重缺陷?？蓞⒖糚SP中缺陷類型標準（如下表），其中缺陷類型是按照問題的復雜度來排列的，類型10到40是比較簡單的編碼缺陷，類型50到100是比較復雜的設計缺陷。類型編號類型名稱描述10文檔注釋，消息20句法拼寫，標點，打字，指令格式30聯(lián)編，打包理改管理，庫，版本控制40分配說明，重名，作用域，限制50接口過程調用和引用，輸入/輸出，用戶格式60檢查出錯信息，不恰當的檢查70數據結構，內容80函數邏輯，指針，循環(huán)，遞歸，計算，函數缺陷90系統(tǒng)配置，記時，內存100環(huán)境設計，編譯，測試，或其它支持系統(tǒng)問題FounderR&D缺陷分析的關注點3、應對軟件缺陷類型進9缺陷分析的關注點4、應動態(tài)采集每個測試周期中發(fā)現(xiàn)的bug數，并有效地控制缺陷的修復率。5、應密切觀察bug的狀態(tài)，并及時跟蹤其狀態(tài)的變化，以檢查測試和開發(fā)人員的工作情況FounderR&D缺陷分析的關注點4、應動態(tài)采集每個測試周期中發(fā)現(xiàn)的bug數，10缺陷分析的關注點6、應該采集bug不同方式的修復數據，以便檢驗軟件產品是否滿足交付規(guī)則分析修改代碼、改變設計、封掉功能遺留以及下一版本解決的bug數約占缺陷總數的比例。在有嚴密和有效的質量保證體系條件的監(jiān)控下，常常會引起有較高比例的延期解決的缺陷數，這是因為許多細微的或枝節(jié)性的問題被測試出來，經過評價證明不會造成大的質量影響，但可為產品進一步升級提供有價值的參考。FounderR&D缺陷分析的關注點6、應該采集bug不同方式的修復數據，以便檢114.2測試人員的績效評價評價標準：1、bug數量：同一個項目組內，提交bug數量的多少是衡量測試人員工作效率的一方面；另一個衡量指標是每人日提交的bug數。2、bug嚴重程度：Bug的嚴重程度是衡量bug的質量的一個重要因素，好的bug應該是極端嚴重的，對系統(tǒng)造成極大危害的。3、bug價值：Bug的雙方面評判，對于bug的價值開發(fā)人員在另外一個角度上進行評判以上三個因素的加權平均才能更有效的評價測試人員的績效！FounderR&D4.2測試人員的績效評價評價標準：FounderR&D124.3缺陷統(tǒng)計分析工具介紹FounderR&D4.3缺陷統(tǒng)計分析工具介紹FounderR&D13測試結果分析和評價缺陷密度:

基本的缺陷測量是以每千行代碼的缺陷數(Defects/KLOC)來測量的。稱為缺陷密度(Dd)，其測量單位是defects／KLOC。可按照以下步驟來計算一個程序的缺陷密度：累計開發(fā)過程中每個階段發(fā)現(xiàn)的缺陷總數(D)。統(tǒng)計程序中新開發(fā)的和修改的代碼行數(N)。計算每千行的缺陷數Dd=1000*D/N。例如，一個29.6萬行的源程序總共有145個缺陷，則缺陷密度是：Dd＝1000*145/296000=0.49defects／KLOC。在計算缺陷密度時，最重要的是要使用正確的規(guī)模測量。FounderR&D測試結果分析和評價缺陷密度:FounderR&D14測試結果的分析和評價輸出《測試綜合報告》：測試過程的總結測試數據分析（按照嚴重程度等方式分類統(tǒng)計的分析，包括測試密度等）產品主要問題和總體評價遺留的問題總結最終的測試結論FounderR&D測試結果的分析和評價輸出《測試綜合報告》：FounderR15測試結果分析和評價為了了解和控制缺陷帶來的費用，很有必要測量缺陷排除的效果測量：一種測量方法是計算每小時排除缺陷的個數；一種是計算缺陷排除效益，即測量通過某一排除方法所發(fā)現(xiàn)的缺陷的百分比。缺陷排除效益是45%100個缺陷開始測試測試發(fā)現(xiàn)45個缺陷missing55defectsFounderR&D測試結果分析和評價為了了解和控制缺陷帶來的費用，很有必要測量16測試結果分析和評價測試覆蓋率測量語句覆蓋率 測試經歷語句數/總語句數分支覆蓋率 測試經歷支路數/總支路數簡單路徑覆蓋率 測試經歷簡單路徑數/總簡單路徑數功能覆蓋率 界面數菜單數輸入/輸出的數據元數構件、模塊…FounderR&D測試結果分析和評價測試覆蓋率測量FounderR&D174.5軟件測試經驗分享所有的測試都應追溯到需求。因最嚴重的錯誤是導致程序無發(fā)滿足需求的錯誤；軟件開發(fā)人員和管理人員首先應該盡早地和不斷地進行各種軟件質量保證活動（如需求和設計階段同行評審和走查等）;軟件開發(fā)人員應避免檢查自已的程序，利用同行評審的方式對代碼進行審查；(自己檢查容易依照原有的程序設計思路進行，往往查不出問題)在設計測試用例時，必須明確預期的輸出結果，否則對實際的輸出結果很難有檢驗的標準，測試失去意義。測試用例應由輸入數據和與之對應的期望輸出結果這兩部分組成，在輸入數據中，應當包括合理的輸入條件和不合理的輸入條件；在進行各種分析和修復工作中，要充分注意修復工作所產生的影響效果和波及效果。FounderR&D4.5軟件測試經驗分享所有的測試都應追溯到需求。因最嚴重的錯18軟件測試經驗分享統(tǒng)計表明大約有60%的錯誤是在設計階段之前注入的，并且修正一個軟件錯誤所需的費用將隨著軟件生存期的進展而上升。錯誤發(fā)現(xiàn)得越晚，修復它的費用就越高，而且呈指數增長的趨勢。測試后程序中殘存的錯誤數目與該程序中已發(fā)現(xiàn)的錯誤數目（即檢錯率）很可能成正比；(編碼規(guī)范、需求理解、技術能力、內部耦合性是引起這些現(xiàn)象的原因)程序中的大部分錯誤往往是在一小部分模塊中發(fā)現(xiàn)的，遵循普遍適用的“二八定理”（即80%的錯誤往往是由20%的模塊所造成的），例如，IBM公司的OS/370操作系統(tǒng)中，47%的錯誤僅與該系統(tǒng)中的4%的程序模塊有關；要嚴格執(zhí)行測試計劃，排除測試的隨意性，這樣才能消除各種無序操作所造成的副作用；測試設計決定了測試的有效性和效率，測試工具只能提高測試效率應當對每一個測試結果做全面的檢查，這樣才有可能找到真正的出錯原因，為今后的調試工作奠定基礎。FounderR&D軟件測試經驗分享統(tǒng)計表明大約有60%的錯誤是在設計階段之前注19結束語產品越復雜，測試花費的時間就越長，費用就越大，測試發(fā)現(xiàn)缺陷的效率也就越低。缺陷會掩蓋或加重其它缺陷。也就是說，當一個程序有許多缺陷時，由于缺陷相互作用，使得發(fā)現(xiàn)和修復缺陷的過程更加復雜。這使得一些缺陷很難查找和修復。一個缺陷可能掩蓋其它缺陷，使得這些被掩蓋的缺陷難以發(fā)現(xiàn)，增加了它們逃過測試的可能性。遵照規(guī)范化的方法，仔細復查和測試每個小程序模塊，這比讓任何測試組在你的程序中發(fā)現(xiàn)缺陷的效果要好。也就是說，盡早的將缺陷排除掉。測試不能避免缺陷的發(fā)生，只能是一種補救。

你是唯一能做到生產出無缺陷程序的人，其他任何人都無法幫你做到這一點。FounderR&D結束語產品越復雜，測試花費的時間就越長，費用就越大，測試發(fā)現(xiàn)20希望對大家有幫助Q&A希望對大家有幫助Q&A21演講完畢，謝謝觀看！演講完畢，謝謝觀看！22三、基于測試流程上的缺陷管理系統(tǒng)缺陷的定義軟件沒有達到產品說明書表明的功能軟件出現(xiàn)了產品說明書中不一致的表現(xiàn)軟件功能超出產品說明書的范圍軟件沒有達到用戶期望的目標(雖然產品說明書中沒有要求)測試員或用戶認為軟件的易用性差不是所有缺陷都會修改市場的壓力使得產品最終發(fā)行有時間限制測試員錯誤理解或者不正確操作引出的缺陷(FAQ)錯誤的修改影響的模塊較多，帶來的風險較大（遺留）修改性價比太低(FAQ，遺留）缺陷報告中提出的問題很難重現(xiàn)FounderR&D三、基于測試流程上的缺陷管理系統(tǒng)缺陷的定義FounderR233.1缺陷報告管理系統(tǒng)是測試流程在工具上的固化通過權限控制來實現(xiàn)流程監(jiān)控記錄了缺陷識別到關閉過程中的所有數記錄了版本變更的信息是開發(fā)和測試之間溝通的信息平臺實時的數據和信息的更新度量和統(tǒng)計分析，為改進產品提供依據FounderR&D3.1缺陷報告管理系統(tǒng)是測試流程在工具上的固化Founde24FounderR&D采用LotusNotes作為bug管理平臺完全電子化的信息傳遞統(tǒng)一管理和備份具備數據統(tǒng)計和查詢功能能夠進行個性化二次開發(fā)方正測試缺陷跟蹤與管理系統(tǒng)FounderR&D采用LotusNotes作為bug管253.1.1系統(tǒng)測試缺陷處理流程新建表單待測試提交待指定處理人正在處理返回處理待開發(fā)提交待返測待歸檔已歸檔個人提交退回測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回提交版本更新說明FounderR&D3.1.1系統(tǒng)測試缺陷處理流程新建表單待測試提交待指26Bug報告準則如何重現(xiàn)錯誤-使用最少步驟重現(xiàn)現(xiàn)象描述沒有歧義盡量簡單-一個bug一個報告可以提出對錯誤的解決建議開發(fā)人員拒絕修改的bug程序員無法重現(xiàn)或者現(xiàn)象難以捕捉沒有明確的報告以說明重現(xiàn)bug的步驟程序員無法讀懂的bug報告用戶很少使用或者不符合用戶使用習慣的操作出錯由不受信任的測試人員提出缺陷報告FounderR&D缺陷報告FounderR&D273.1.2集成測試缺陷處理流程新建表單待指定處理人正在處理待返測待歸檔已歸檔返回處理測試提交指定處理人重新指定處理完畢返測完畢歸檔重新返測退回FounderR&D3.1.2集成測試缺陷處理流程新建表單待指定處理人284.1缺陷分析的關注點：1、對軟件問題的功能域分布進行分析，找出系統(tǒng)的薄弱環(huán)節(jié)要詳細采集每個功能模塊或系統(tǒng)構件的bug數據，并按功能、錯誤類型、嚴重程度等分類比較實際發(fā)現(xiàn)的軟件bug是否與預期的問題分布相吻合二八定理：80%的軟件問題總是發(fā)生在大約20%的功能模塊（系統(tǒng)構件）中。FounderR&D4.1缺陷分析的關注點：1、對軟件問題的功能域分布進行分析29缺陷分析的關注點2、對bug的注入階段的分布進行分析，并與歷史數據相比較。應按不同的開發(fā)階段詳細采集bug的數據要求軟件各開發(fā)階段的缺陷密度小于本單位過去的平均值而且要求需求分析、設計和代碼復查階段的缺陷排除率之和大于或等于規(guī)定值（例如75%）。（同行評審）FounderR&D缺陷分析的關注點2、對bug的注入階段的分布進行分析，并與歷30FounderR&D缺陷分析的關注點3、應對軟件缺陷類型進行分析，以便針對各自的特點，先修復嚴重缺陷?？蓞⒖糚SP中缺陷類型標準（如下表），其中缺陷類型是按照問題的復雜度來排列的，類型10到40是比較簡單的編碼缺陷，類型50到100是比較復雜的設計缺陷。類型編號類型名稱描述10文檔注釋，消息20句法拼寫，標點，打字，指令格式30聯(lián)編，打包理改管理，庫，版本控制40分配說明，重名，作用域，限制50接口過程調用和引用，輸入/輸出，用戶格式60檢查出錯信息，不恰當的檢查70數據結構，內容80函數邏輯，指針，循環(huán)，遞歸，計算，函數缺陷90系統(tǒng)配置，記時，內存100環(huán)境設計，編譯，測試，或其它支持系統(tǒng)問題FounderR&D缺陷分析的關注點3、應對軟件缺陷類型進31缺陷分析的關注點4、應動態(tài)采集每個測試周期中發(fā)現(xiàn)的bug數，并有效地控制缺陷的修復率。5、應密切觀察bug的狀態(tài)，并及時跟蹤其狀態(tài)的變化，以檢查測試和開發(fā)人員的工作情況FounderR&D缺陷分析的關注點4、應動態(tài)采集每個測試周期中發(fā)現(xiàn)的bug數，32缺陷分析的關注點6、應該采集bug不同方式的修復數據，以便檢驗軟件產品是否滿足交付規(guī)則分析修改代碼、改變設計、封掉功能遺留以及下一版本解決的bug數約占缺陷總數的比例。在有嚴密和有效的質量保證體系條件的監(jiān)控下，常常會引起有較高比例的延期解決的缺陷數，這是因為許多細微的或枝節(jié)性的問題被測試出來，經過評價證明不會造成大的質量影響，但可為產品進一步升級提供有價值的參考。FounderR&D缺陷分析的關注點6、應該采集bug不同方式的修復數據，以便檢334.2測試人員的績效評價評價標準：1、bug數量：同一個項目組內，提交bug數量的多少是衡量測試人員工作效率的一方面；另一個衡量指標是每人日提交的bug數。2、bug嚴重程度：Bug的嚴重程度是衡量bug的質量的一個重要因素，好的bug應該是極端嚴重的，對系統(tǒng)造成極大危害的。3、bug價值：Bug的雙方面評判，對于bug的價值開發(fā)人員在另外一個角度上進行評判以上三個因素的加權平均才能更有效的評價測試人員的績效！FounderR&D4.2測試人員的績效評價評價標準：FounderR&D344.3缺陷統(tǒng)計分析工具介紹FounderR&D4.3缺陷統(tǒng)計分析工具介紹FounderR&D35測試結果分析和評價缺陷密度:

基本的缺陷測量是以每千行代碼的缺陷數(Defects/KLOC)來測量的。稱為缺陷密度(Dd)，其測量單位是defects／KLOC。可按照以下步驟來計算一個程序的缺陷密度：累計開發(fā)過程中每個階段發(fā)現(xiàn)的缺陷總數(D)。統(tǒng)計程序中新開發(fā)的和修改的代碼行數(N)。計算每千行的缺陷數Dd=1000*D/N。例如，一個29.6萬行的源程序總共有145個缺陷，則缺陷密度是：Dd＝1000*145/296000=0.49defects／KLOC。在計算缺陷密度時，最重要的是要使用正確的規(guī)模測量。FounderR&D測試結果分析和評價缺陷密度:FounderR&D36測試結果的分析和評價輸出《測試綜合報告》：測試過程的總結測試數據分析（按照嚴重程度等方式分類統(tǒng)計的分析，包括測試密度等）產品主要問題和總體評價遺留的問題總結最終的測試結論FounderR&D測試結果的分析和評價輸出《測試綜合報告》：FounderR37測試結果分析和評價為了了解和控制缺陷帶來的費用，很有必要測量缺陷排除的效果測量：一種測量方法是計算每小時排除缺陷的個數；一種是計算缺陷排除效益，即測量通過某一排除方法所發(fā)現(xiàn)的缺陷的百分比。缺陷排除效益是45%100個缺陷開始測試測試發(fā)現(xiàn)45個缺陷missing55defectsFounderR&D測試結果分析和評價為了了解和控制缺陷帶來的費用，很有必要測量38測試結果分析和評價測試覆蓋率測量語句覆蓋率 測試經歷語句數/總語句數分支覆蓋率 測試經歷支路數/總支路數簡單路徑覆蓋率 測試經歷簡單路徑數/總簡單路徑數功能覆蓋率 界面數菜單數輸入/輸出的數據元數構件、模塊…FounderR&D測試結果分析和評價測試覆蓋率測量FounderR&D394.5軟件測試經驗分享所有的測試都應追溯到需求。因最嚴重的錯誤是導致程序無發(fā)滿足需求的錯誤；軟件開發(fā)人員和管理人員首先應該盡早地和不斷地進行各種軟件質量保證活動（如需求和設計階段同行評審和走查等）;軟件開發(fā)人員應避免檢查自已的程序，利用同行評審的方式對代碼進行審查；(自己檢查容易依照原有的程序設計思路進行，往往查不出問題)在設計測試用例時，必須明確預期的輸出結果，否則對實際的輸出結果很難有檢驗的標準，測試失去意義。測試用例應由輸入數據和與之對應的期望輸出結果這兩部分組成，在輸入數據中，應當包括合理的輸入條件和不合理的輸入條件；在進